Aventora Data Classification and Handling Policy

Field	Value
Document Name	Data Classification and Handling Policy
Version	1.0
Effective Date	July 6, 2026
Owner	Aventora Security
Review Frequency	Annually
Classification	Public / Customer Shareable

---

Document Control

This policy establishes Aventora Inc. (“Aventora,” “we,” “us,” or “our”) requirements for classifying, labeling, storing, processing, transmitting, sharing, retaining, and disposing of information throughout its lifecycle.

Aventora operates an AI-powered customer engagement platform that enables organizations to manage communications and customer interactions across channels such as voice, SMS, email, chat, and related administrative workflows. Information handled by Aventora includes Aventora business data, operational data, and customer-supplied data processed on behalf of enterprise customers.

This document is intended for enterprise customers, security assessors, compliance reviewers, and Aventora personnel. It supports security reviews and aligns with common control themes relevant to future compliance initiatives (for example, SOC 2, ISO 27001, PIPEDA, GDPR, and UK GDPR). Aventora does not claim formal certification or attestation under any specific security or privacy framework based on this document alone. Implementation details may vary by deployment model, contractual terms, and enabled product features.

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.

Related Documents

Document	Relationship
Customer Security Package	Index of customer-shareable security documentation
Personal Data Privacy & Protection Policy	Privacy-specific requirements for personal information
Information Security Risk Management Policy	Risk identification and impact assessment governance
Risk Assessment and Treatment Procedure	Likelihood/impact scoring methodology
Logging and Audit	Logging, audit trails, and monitoring expectations
Data Retention	Retention categories and deletion signals
Incident Response	Security incident reporting and response
Subprocessor Annex	Third-party processors engaged by Aventora

---

Table of Contents

1. Purpose
2. Scope
3. Objectives
4. Roles and Responsibilities
5. Data Classification Levels
6. Data Ownership
7. Data Labeling Requirements
8. Data Handling Requirements
9. Encryption Requirements
10. Access Control
11. Logging and Monitoring
12. Data Sharing
13. Data Retention
14. Secure Disposal
15. Development Environment Requirements
16. Third-Party Providers
17. Customer Data
18. Incident Handling
19. Exceptions
20. Compliance
21. Policy Violations
22. Review
23. Version History

---

1. Purpose

The purpose of this Data Classification and Handling Policy is to define how Aventora identifies, classifies, protects, and manages information assets based on sensitivity, business value, and regulatory or contractual obligations.

Effective data classification enables Aventora to:

• Apply appropriate security controls proportionate to information sensitivity;
• Protect the confidentiality, integrity, and availability of information throughout its lifecycle;
• Support enterprise customer security assessments and due diligence;
• Provide a consistent framework for personnel, contractors, and third parties who create, access, or manage Aventora or customer information; and
• Align operational practices with applicable legal, regulatory, and contractual requirements without asserting certification status.

This policy complements Aventora’s privacy, access control, encryption, logging, and incident response policies. Where personal information is involved, the Personal Data Privacy & Protection Policy also applies.

---

2. Scope

2.1 In Scope

This policy applies to all information created, received, stored, processed, transmitted, or disposed of by or on behalf of Aventora, regardless of format or medium.

Area	Description
Employees	Full-time and part-time Aventora personnel
Contractors	Temporary workers, consultants, and agency staff with access to Aventora systems or information
Third-party service providers	Vendors, subprocessors, and partners engaged by Aventora who process or access information on Aventora’s behalf
All Aventora systems	Production, staging, development, testing, administrative, and support systems
Customer environments	Aventora-managed tenant environments and deployments operated on behalf of customers
Development	Source code repositories, build pipelines, local development environments, and design artifacts
Testing	Quality assurance, pre-production, and pilot environments
Production	Live services, databases, integrations, backups, and operational infrastructure

2.2 Information Types

This policy applies to, but is not limited to:

• Customer-supplied data and data generated on behalf of customers;
• Aventora business records, contracts, and financial information;
• Source code, configuration, and infrastructure definitions;
• Credentials, API keys, tokens, and encryption keys;
• Operational logs, audit records, and security investigation evidence;
• Marketing, product, and internal documentation; and
• Physical and electronic media containing any of the above.

2.3 Deployment Models

This policy applies across Aventora-managed cloud deployments, customer-specific deployments, and self-hosted models. Customer deployments are hosted in approved cloud environments and may use Canadian regions where contractually required or agreed. Customer-specific deployments may vary based on contractual requirements, technical feasibility, and enabled product features.

Variations from default handling requirements MUST be documented and approved through Aventora’s exception process (see Section 19).

2.4 Out of Scope

Unless explicitly addressed in a written agreement, the following remain outside the scope of this policy:

• Customer-managed systems, networks, and data stores not operated by or on behalf of Aventora;
• Information processed by customers independently of the Aventora platform; and
• Third-party services configured or operated directly by the customer outside Aventora’s control.

---

3. Objectives

3.1 Protect Information Security Properties

Aventora MUST protect information according to its classification level to preserve:

Property	Objective
Confidentiality	Information is accessible only to authorized individuals, systems, and processes
Integrity	Information is accurate, complete, and protected from unauthorized modification
Availability	Information and systems are accessible to authorized users when required for legitimate business purposes

3.2 Support Core Security Principles

Data handling practices MUST support the following principles:

Principle	Description
Least privilege	Access to information is limited to the minimum necessary for assigned duties
Need-to-know	Personnel receive access only to information required to perform their role
Data minimization	Aventora collects, stores, and processes only the information necessary to deliver contracted services and operate the platform

Data minimization is a core design principle across Aventora products and operations. Security and privacy considerations MUST be integrated throughout the software development lifecycle.

---

4. Roles and Responsibilities

All personnel with access to Aventora or customer information MUST understand and comply with this policy. Specific responsibilities are assigned as follows.

4.1 Management

Management, including executive leadership and functional managers, is responsible for:

• Approving and endorsing this policy and related security standards;
• Ensuring adequate resources for classification, protection, and disposal of information;
• Promoting a culture of security awareness and accountability;
• Reviewing exception requests and risk acceptance decisions;
• Ensuring periodic access reviews and policy compliance are performed; and
• Escalating significant data handling incidents to Aventora Security.

4.2 Engineering

Engineering teams are responsible for:

• Implementing technical controls aligned with data classification requirements;
• Applying secure development practices, including input validation, authorization checks, and secure configuration;
• Ensuring secrets are not stored in source code and are managed through approved mechanisms;
• Designing systems to minimize collection and retention of sensitive information;
• Documenting data flows and classification implications for new features; and
• Supporting secure disposal, anonymization, and masking in non-production environments.

4.3 Operations

Operations teams are responsible for:

• Maintaining production infrastructure, backups, monitoring, and deployment pipelines;
• Enforcing access controls, MFA, and least privilege for operational systems;
• Protecting Restricted information such as production credentials and backup stores;
• Responding to operational incidents affecting data confidentiality, integrity, or availability;
• Executing retention and disposal procedures for operational data and backups; and
• Coordinating with Aventora Security on infrastructure-related data handling issues.

4.4 Support

Support personnel are responsible for:

• Accessing customer information only when authorized and necessary to resolve support requests;
• Following need-to-know and least privilege when viewing customer tenant data;
• Not exporting, copying, or sharing customer information outside approved channels;
• Reporting suspected data mishandling, misclassification, or unauthorized disclosure promptly; and
• Using secure communication channels when handling Confidential or Restricted information.

4.5 Contractors

Contractors and temporary personnel MUST:

• Comply with this policy and applicable confidentiality agreements;
• Access information only through authorized systems and for assigned tasks;
• Return or destroy Aventora information upon completion of engagement;
• Report security incidents and policy violations to their Aventora sponsor and Aventora Security; and
• Complete required security awareness training before accessing Confidential or Restricted information.

4.6 Aventora Security

Aventora Security is responsible for:

• Owning, maintaining, and reviewing this policy;
• Providing classification guidance and handling standards;
• Coordinating incident response for data leakage and unauthorized disclosure;
• Conducting or coordinating vendor security assessments where applicable;
• Maintaining exception records and risk acceptance documentation; and
• Supporting enterprise customer security reviews.

---

5. Data Classification Levels

Aventora uses a four-tier classification scheme. When information could reasonably fall into more than one level, the highest applicable classification MUST be applied.

If uncertainty exists, personnel MUST treat information as Confidential until Aventora Security or the applicable Business Owner confirms the classification.

5.1 Public

Definition: Information approved for unrestricted disclosure to the general public. Unauthorized modification or misrepresentation remains unacceptable.

Examples:

• Published marketing materials and public website content;
• Public product documentation and openly published API reference material intended for external audiences;
• Press releases and public announcements;
• Job postings and publicly available corporate information; and
• Open-source components and publicly released code where explicitly designated as public.

Handling summary: Public information MAY be shared externally without restriction, but MUST still be published through approved channels to ensure accuracy and brand consistency.

5.2 Internal

Definition: Information intended for use within Aventora that is not approved for public release. Unauthorized disclosure could cause minor operational inconvenience or reduce competitive advantage.

Examples:

• Internal documentation, runbooks, and operational procedures not approved for customer distribution;
• Non-public product roadmaps and internal planning materials;
• Internal meeting notes and team communications;
• Non-customer-specific architecture diagrams for internal use;
• Aggregated operational metrics without customer identifiers; and
• Internal HR and administrative records not containing sensitive personal information.

Handling summary: Internal information MUST NOT be disclosed externally without authorization. Internal sharing is permitted among Aventora personnel with a legitimate business need.

5.3 Confidential

Definition: Sensitive business or customer information whose unauthorized disclosure, modification, or loss could cause material harm to Aventora, its customers, or individuals. This is the default classification for customer-supplied data unless a higher or lower classification is documented and approved.

Examples:

• Customer information, including contact details, engagement records, and conversation content processed on behalf of customers;
• Quotes, statements of work, contracts, and commercial agreements;
• Business records, financial forecasts, and non-public pricing;
• Configuration information describing customer deployments, integrations, and tenant settings;
• API endpoints, service URLs, and integration metadata associated with customer environments;
• Application and infrastructure logs containing customer information or tenant identifiers;
• Support tickets and troubleshooting records referencing customer data; and
• Pre-release product documentation shared under confidentiality with customers or partners.

Handling summary: Confidential information MUST be protected against unauthorized access, transmission, and disclosure. Access MUST be limited to authorized personnel on a need-to-know basis.

5.4 Restricted / Highly Confidential

Definition: The most sensitive classification. Unauthorized disclosure, loss, or compromise could cause severe harm, including regulatory penalties, significant customer impact, loss of cryptographic protection, or compromise of production systems.

Examples:

• Credentials, passwords, and authentication secrets;
• API keys, access tokens, OAuth refresh tokens, and session secrets;
• Encryption keys, key material, and certificate private keys;
• Production database backups and full database exports;
• Infrastructure configuration secrets and privileged automation credentials;
• Security investigation evidence, forensic images, and vulnerability assessment reports containing exploitable details;
• Personal information subject to heightened legal protection when so classified by law or contract; and
• Any aggregation of Confidential data that materially increases sensitivity (for example, bulk customer exports).

Handling summary: Restricted information MUST receive the strongest controls available in the deployment environment. Access MUST be strictly limited, monitored, and time-bound where feasible.

---

6. Data Ownership

Clear ownership ensures accountability for classification decisions and lifecycle management.

6.1 Business Owner

The Business Owner is the Aventora leader or designated manager accountable for a data set or information domain. Business Owners are responsible for:

• Determining or approving the classification of information within their domain;
• Defining authorized uses and sharing rules;
• Approving access for non-routine requests;
• Ensuring retention and disposal align with business and legal requirements; and
• Reviewing classification when systems, contracts, or regulations change.

For customer data processed on behalf of a customer, the customer retains ownership of the underlying information (see Section 17). Aventora acts as a custodian and processor under the applicable agreement.

6.2 Data Custodian

The Data Custodian is the individual or team responsible for implementing technical and operational controls on behalf of the Business Owner. Data Custodians are typically Engineering or Operations personnel and are responsible for:

• Implementing storage, backup, access control, and encryption controls;
• Maintaining systems in accordance with approved classification handling requirements;
• Executing retention, archival, and secure disposal procedures;
• Monitoring access and alerting on anomalous activity where implemented; and
• Reporting control gaps or incidents to the Business Owner and Aventora Security.

6.3 Users

Users are employees, contractors, and authorized third parties who access information to perform their duties. Users are responsible for:

• Handling information according to its classification;
• Accessing only information necessary for their role;
• Protecting credentials and access mechanisms;
• Labeling information they create when required by Section 7;
• Reporting suspected mishandling, misclassification, or unauthorized disclosure; and
• Completing required security awareness training.

---

7. Data Labeling Requirements

Accurate labeling helps personnel and systems apply appropriate handling controls.

7.1 General Labeling Requirements

Documents, reports, exports, and formal communications containing Confidential or Restricted information SHOULD include a visible classification label. Acceptable label formats include:

• Document header or footer: Classification: Confidential
• File naming convention prefix where practical: CONFIDENTIAL_, RESTRICTED_, INTERNAL_
• Email subject line tag for sensitive content: [Confidential] or [Restricted]

Public materials MUST NOT carry Internal, Confidential, or Restricted labels unless the label explicitly indicates “Public.”

7.2 Default Classification

Context	Default classification
Customer-supplied data	Confidential, unless classified otherwise by contract or explicit customer instruction
Credentials and secrets	Restricted
Internal business documents	Internal
Published external documentation	Public
Logs in production	Confidential when they contain customer information or tenant identifiers; otherwise Internal
Source code repositories	Internal; Restricted when containing secrets or sensitive configuration

When default classification is insufficient, the Business Owner or Aventora Security MUST define the appropriate level before broader distribution.

7.3 Customer-Supplied Data

Customer-supplied data MUST be treated as Confidential by default, regardless of the customer’s internal classification, unless:

• The customer explicitly designates a different classification in writing and Aventora has agreed to that designation; or
• The data is manifestly public (for example, information already published by the customer for public consumption).

Customers SHOULD inform Aventora of any heightened sensitivity requirements, legal restrictions, or sector-specific handling obligations during onboarding or contract negotiation.

7.4 Electronic Systems and Repositories

Repositories, databases, file shares, and cloud storage locations SHOULD indicate the maximum classification of data they contain through naming conventions, access group labels, or internal documentation. Production systems containing customer data MUST be documented in Aventora’s system inventory with their expected data classification.

---

8. Data Handling Requirements

The following requirements apply to each classification level across the information lifecycle. Controls MUST be implemented using mechanisms appropriate to the deployment environment.

8.1 Public

Control area	Requirements
Storage	MAY be stored on public websites, CDNs, and public repositories without access restrictions
Transmission	MAY be transmitted over public channels; integrity controls SHOULD be used for official publications
Access	No access restrictions required for viewing; modification MUST be limited to authorized publishers
Sharing	MAY be shared freely with external parties
Logging	Standard web and application logging is sufficient
Printing	No restrictions
Export	No restrictions
Mobile devices	No restrictions
Cloud storage	MAY use public or shared storage with appropriate version control
Backups	Standard backup practices apply
Disposal	Update or remove outdated public content through normal publication processes

8.2 Internal

Control area	Requirements
Storage	MUST be stored on Aventora-controlled systems or approved third-party services with access limited to Aventora personnel
Transmission	SHOULD use encrypted channels (TLS) when transmitted over networks; MUST NOT be posted to public forums or unauthorized cloud shares
Access	Limited to Aventora employees, contractors, and authorized third parties with legitimate need
Sharing	External sharing MUST be approved by the Business Owner; NDAs or contractual protections SHOULD be in place
Logging	Access to sensitive internal repositories SHOULD be logged where feasible
Printing	SHOULD be minimized; printed materials MUST be stored securely and disposed of securely when no longer needed
Export	Exports for external use require Business Owner approval
Mobile devices	SHOULD be accessed only through managed or approved devices with screen lock and encryption where supported
Cloud storage	MUST use approved corporate or project accounts; personal cloud storage MUST NOT be used
Backups	MUST be included in standard backup routines with access limited to authorized personnel
Disposal	Secure deletion when no longer needed; see Section 14

8.3 Confidential

Control area	Requirements
Storage	MUST be stored in access-controlled systems; production customer data MUST reside in approved production environments with RBAC enforcement
Transmission	MUST use TLS 1.2 or higher for transmission over networks; MUST NOT be sent via unencrypted email or unsecured messaging
Access	RBAC and least privilege MUST be enforced; access limited to authorized personnel on need-to-know basis
Sharing	Internal sharing permitted on need-to-know basis; external sharing requires Business Owner approval and contractual protections
Logging	Access and significant actions SHOULD be logged; logs containing Confidential data MUST themselves be protected
Printing	SHOULD be avoided; when necessary, MUST be labeled, tracked, and securely disposed of
Export	Exports MUST be approved, encrypted where practical, and transferred through secure channels; bulk exports require additional approval
Mobile devices	Access SHOULD be through approved devices with encryption and screen lock; local copies SHOULD be minimized and removed when no longer needed
Cloud storage	MUST use approved corporate or customer-contracted cloud environments; personal or unsanctioned cloud storage MUST NOT be used
Backups	MUST be encrypted where supported; backup access MUST be restricted; backup locations MUST meet equivalent classification controls
Disposal	Secure deletion required; see Section 14

8.4 Restricted / Highly Confidential

Control area	Requirements
Storage	MUST be stored in hardened, access-controlled systems; secrets MUST use secure secret management and MUST NOT be stored in source code
Transmission	MUST use TLS 1.2 or higher; secrets MUST NOT be transmitted via email, chat, or tickets; secure secret-sharing tools SHOULD be used when transmission is unavoidable
Access	Strict least privilege; privileged access MUST use MFA; access SHOULD be time-limited and monitored
Sharing	External sharing MUST be approved by Aventora Security and the Business Owner; sharing MUST be limited to the minimum necessary and protected by contract
Logging	Access MUST be logged and monitored; failed access attempts MUST be recorded
Printing	MUST NOT be printed except where legally required; printed Restricted material MUST be physically secured and cross-cut shredded when destroyed
Export	Strongly discouraged; requires Aventora Security approval, encryption, and documented business justification
Mobile devices	Local storage of Restricted data on mobile devices SHOULD be avoided; if unavoidable, device encryption and remote wipe capability MUST be enabled
Cloud storage	MUST use approved secret management or encrypted storage with restricted IAM policies; public buckets and repositories MUST NOT contain Restricted data
Backups	MUST be encrypted; backup access MUST be limited to authorized operations personnel; restoration MUST be logged
Disposal	Cryptographic erasure, secure deletion, or destruction of media; see Section 14

---

9. Encryption Requirements

Encryption is a mandatory control for protecting sensitive information in transit and at rest.

9.1 Encryption in Transit

TLS MUST be used for data in transit for all production services, administrative interfaces, API communications, and integrations. Aventora production environments MUST protect communications using TLS 1.2 or higher.

Connections to databases, subprocessors, webhooks, and third-party APIs SHOULD use encrypted channels where supported by the provider. Unencrypted transmission of Confidential or Restricted information over public networks in production environments MUST NOT occur.

9.2 Encryption at Rest

Aventora enables encryption at rest for production data stores where supported by the hosting provider.

Application-level encryption SHOULD be applied to highly sensitive fields (for example, OAuth tokens and external integration secrets) where warranted by risk assessment or customer requirements.

9.3 Secrets Management

The following requirements apply to all Restricted credentials and secrets:

• Secrets MUST NOT be stored in source code, committed configuration files, or public repositories; Secrets MUST be supplied through secure configuration mechanisms appropriate to the deployment environment, including restricted deployment configuration and centralized vault services where deployed.
• Secrets MUST NOT be logged, included in support tickets, or embedded in documentation;
• API keys and service credentials SHOULD be scoped to minimum permissions and rotated upon compromise, personnel change, or according to defined schedules; and
• Personnel MUST use secure secret-sharing tools when secrets must be transmitted between authorized parties.

9.4 Key Management

Encryption keys and certificate private keys are classified as Restricted. Key access MUST be limited to authorized systems and personnel. Key rotation SHOULD follow provider best practices and be performed upon suspected compromise or according to defined schedules.

---

10. Access Control

Access to information MUST be governed by role, business need, and classification level.

10.1 Role-Based Access Control

Aventora MUST implement role-based access control (RBAC) across platform and administrative systems. Permissions MUST be assigned according to job function and enforced server-side. Client applications MUST NOT be relied upon as the sole enforcement mechanism.

Customer tenants MUST support role and permission assignment for customer administrative users where the product provides such capability.

10.2 Least Privilege

The principle of least privilege MUST be applied to:

• Production infrastructure, hosting consoles, and databases;
• Source code repositories and deployment pipelines;
• API keys, service accounts, and integration credentials;
• Support and engineering access to customer environments; and
• Third-party integrations and webhook endpoints.

Default-deny access models SHOULD be used where feasible. Standing privileged access SHOULD be minimized in favor of just-in-time access where supported.

10.3 Multi-Factor Authentication

MFA is required for privileged administrative access to Aventora production systems and administrative interfaces, including:

• Cloud provider accounts (for example, AWS);
• Source code, CI/CD, and deployment platforms;
• Production hosting, database administration, and backup management; and
• Administrative application access where MFA is supported and enabled.

Customers SHOULD enable MFA for their administrative users where the platform supports it.

10.4 Periodic Access Review

Aventora SHOULD conduct periodic reviews of:

• Privileged accounts and production access grants;
• Outstanding API keys and service credentials;
• Contractor and vendor access; and
• Customer support access permissions.

Access MUST be revoked promptly upon role change, termination, or completion of the business need. Review frequency SHOULD be at least annually for standard access and more frequently for highly privileged access.

10.5 Customer Environment Access

Aventora personnel MUST NOT access customer environments beyond permissions authorized by the customer and Aventora’s contractual obligations. Support access SHOULD be logged and limited to the minimum necessary to resolve the request.

---

11. Logging and Monitoring

Logging and monitoring support security detection, incident investigation, and operational accountability.

11.1 Logging Expectations

Logging and monitoring MUST be enabled for production environments. Logs SHOULD capture relevant security and operational events, including:

• Authentication successes and failures;
• Authorization denials and privilege escalation;
• Administrative and configuration changes;
• API and integration errors affecting data processing;
• Backup and restore operations involving Confidential or Restricted data; and
• Application and infrastructure health indicators.

Log content SHOULD be minimized and redacted where feasible. Secrets, credentials, full payment card numbers, and unnecessary personal information MUST NOT be written to logs.

11.2 Security Monitoring

Aventora SHOULD monitor production systems for anomalies indicative of unauthorized access, data exfiltration, or service degradation. Monitoring scope MAY include:

• Failed authentication patterns;
• Unusual API usage or bulk export activity;
• Infrastructure configuration changes; and
• Integration and webhook failures.

Alerting and escalation procedures SHOULD be defined for suspected security events. See Incident Response.

11.3 Audit Trails

Audit trails SHOULD be maintained for actions affecting customer data, administrative configuration, and access control changes. Audit records classified as Confidential or Restricted MUST be protected with equivalent or stronger controls than the data they describe.

Centralized log aggregation and immutable archival are implemented where required by deployment scale, customer requirements, or contractual obligations.

11.4 Log Classification

Log type	Typical classification
Logs without customer identifiers	Internal
Logs containing customer information or tenant identifiers	Confidential
Logs containing credentials, tokens, or security investigation details	Restricted

---

12. Data Sharing

Data sharing MUST comply with classification handling requirements and applicable contractual obligations.

12.1 Internal Sharing

Internal sharing of Confidential and Restricted information MUST be limited to personnel with a legitimate need-to-know. Personnel MUST verify classification before forwarding information and MUST use approved secure channels.

Aggregating data across customers for analytics or product improvement MUST NOT include customer-identifiable information unless permitted by contract and applicable law.

12.2 Sharing with Customers

Aventora MAY share information with customers as necessary to deliver contracted services, provide reports, respond to support requests, or fulfill contractual reporting obligations. Shared information MUST be limited to the customer’s own data unless otherwise authorized.

Customer-requested exports MUST be delivered through secure channels and SHOULD be encrypted.

12.3 Sharing with Third Parties

Third parties MUST NOT receive Confidential or Restricted information unless:

• A written agreement is in place requiring appropriate security and confidentiality protections;
• The sharing is necessary to deliver contracted services or operate the platform;
• The minimum necessary data is shared; and
• The Business Owner or Aventora Security has approved the sharing where required.

12.4 Subprocessors

Aventora MAY engage subprocessors to support platform delivery. Subprocessors MUST be subject to vendor assessment and contractual obligations consistent with the sensitivity of data processed. The current list of subprocessors is maintained in the Subprocessor Annex.

Subprocessor engagement MUST follow data minimization principles. Subprocessors MUST process information only as instructed by Aventora and MUST NOT use customer data for their own marketing or unrelated purposes.

12.5 Legal Disclosures

If Aventora receives a request from law enforcement or other authority for customer information, Aventora SHOULD redirect the request to the customer where permitted and SHOULD notify the customer unless prohibited by law. Aventora MUST disclose only the minimum information required by valid legal process and MUST document the disclosure.

---

13. Data Retention

Information MUST be retained only for as long as necessary to fulfill its purpose and meet legal, regulatory, and contractual obligations.

13.1 Operational Data

Operational data, including customer engagement records, configuration, and tenant content, MUST be retained according to:

• Contractual terms with the customer;
• Customer-configured settings where available;
• Operational requirements for service delivery; and
• Applicable legal and regulatory requirements.

When no longer required, operational data MUST be deleted or returned to the customer in accordance with the applicable agreement.

13.2 Logs

Security and application logs are retained according to Aventora’s Data Retention Policy and applicable customer agreements.

Logs containing Confidential or Restricted information MUST be protected throughout their retention period and securely disposed of when retention expires.

13.3 Backups

Backup retention MUST align with recovery objectives and contractual requirements. Backups containing customer data MUST be treated with the same classification as the source data. Backup encryption SHOULD be enabled where supported.

Expired backups MUST be purged according to defined retention cycles. Backup restoration MUST be logged and limited to authorized personnel.

13.4 Customer-Requested Deletion

Upon verified customer request or contract termination, Aventora MUST delete or return customer data in accordance with the applicable agreement, subject to:

• Technical feasibility and defined deletion procedures;
• Secure backup expiry cycles (data in backups MAY persist until backup rotation completes); and
• Legal retention obligations.

Deletion actions SHOULD be documented where contractually required.

13.5 Legal Hold

When litigation, regulatory inquiry, or internal investigation requires preservation of information, Aventora MUST suspend routine deletion for affected data sets upon direction by Aventora Security or Legal. The scope, duration, and custodian of the legal hold MUST be documented. Personnel MUST NOT alter or destroy information subject to legal hold.

---

14. Secure Disposal

When information is no longer required and not subject to legal hold, it MUST be disposed of securely according to its classification.

14.1 Electronic Data

Secure disposal of electronic data SHOULD include one or more of the following, appropriate to the environment:

• Permanent deletion from active databases and application stores with verification;
• Cryptographic erasure through destruction of encryption keys where used;
• Overwriting or secure wipe of storage media where cryptographic erasure is not available; and
• Coordinated deletion across replicas, caches, and search indexes where applicable.

Restricted data MUST NOT remain recoverable through casual deletion methods.

14.2 Backups

Expired backups MUST be purged according to defined retention schedules. Backup disposal MUST ensure that Confidential and Restricted information is not recoverable beyond the approved retention period.

14.3 Temporary Files

Temporary files, export staging areas, crash dumps, and diagnostic artifacts containing Confidential or Restricted information MUST be deleted after use or according to automated cleanup schedules. Development and support personnel MUST NOT retain customer data in local temporary directories beyond the immediate need.

14.4 Media Sanitization

Physical media (hard drives, removable storage, printed materials) that contained Restricted information MUST be sanitized or destroyed before reuse or disposal. Methods include cross-cut shredding for paper, degaussing or physical destruction for magnetic media, and secure erase or destruction for solid-state storage.

Cloud-hosted storage disposal relies on provider secure deletion capabilities; Aventora MUST verify that provider disposal meets organizational requirements for the classification level involved.

14.5 Subprocessor Disposal

Contracts with subprocessors SHOULD require return or deletion of information upon termination of the processing relationship, except where retention is required by law. Aventora SHOULD verify subprocessor disposal upon offboarding where practical.

---

15. Development Environment Requirements

Development and testing environments pose elevated risk if production data or secrets are mishandled. The following requirements apply.

15.1 Production Data in Non-Production Environments

Production customer data MUST NOT be used in development, testing, or staging environments without explicit authorization from Aventora Security and the applicable Business Owner.

Where production-like data is required for testing, Aventora SHOULD:

• Use synthetically generated data;
• Mask or anonymize production data to remove or obfuscate identifiers where practical; or
• Use a minimal, approved subset with documented justification and time-bound access.

Authorized use of production data in non-production environments MUST be logged and MUST be deleted when the approved purpose is complete.

15.2 Secrets in Development

Developers MUST NOT commit secrets to source code repositories. Sample configuration files MUST use non-sensitive placeholders. Pre-commit and CI secret scanning SHOULD be used to prevent accidental secret commits.

Development credentials MUST be separate from production credentials and classified at minimum as Internal; production credentials are Restricted.

15.3 Secure Test Environments

Test and staging environments MUST:

• Be access-controlled and not exposed to the public internet without business justification;
• Use TLS for network communications where the environment handles Confidential data;
• Be excluded from production backup and monitoring paths unless explicitly designed as production-equivalent; and
• Be purged of test data according to defined schedules.

Security and privacy considerations MUST be incorporated into design, code review, and release processes for all changes affecting data handling.

---

16. Third-Party Providers

Aventora uses third-party providers to deliver platform capabilities. Third-party relationships MUST be governed by risk assessment, contractual protections, and ongoing review.

16.1 Approved Provider Categories

Aventora MAY use the following categories of third-party providers in connection with platform delivery, depending on enabled features and deployment configuration:

Provider	Typical processing activity
Amazon Web Services (AWS)	Primary cloud hosting: compute, storage, networking, databases, backups
OpenAI	AI inference for conversational features, summarization, and related capabilities where configured
Twilio	Voice, SMS, and messaging services where enabled
Google	OAuth authentication, calendar integrations, and related productivity integrations where enabled
Microsoft	OAuth authentication, Microsoft 365 / Outlook integrations where enabled

Additional subprocessors MAY be engaged for specific features or deployments. The authoritative list is maintained in the Subprocessor Annex.

16.2 Vendor Assessments

Before engaging a new subprocessor that will process Confidential or Restricted information, Aventora SHOULD perform a vendor security assessment commensurate with the sensitivity and volume of data to be processed. Assessments SHOULD consider:

• Security and privacy practices of the vendor;
• Data residency and cross-border transfer implications;
• Authentication, encryption, and access control capabilities;
• Incident notification commitments; and
• Subprocessor further-engagement (fourth-party) practices where relevant.

16.3 Contractual Obligations

Contracts with third-party providers that process customer information on Aventora’s behalf SHOULD include:

• Confidentiality and data protection obligations;
• Purpose limitation and prohibition on unauthorized use or sale of data;
• Security control requirements appropriate to data classification;
• Breach notification timelines;
• Data return or deletion upon termination; and
• Audit or assessment rights where appropriate.

16.4 Security Reviews

Aventora SHOULD periodically review critical third-party providers for continued suitability. Reviews SHOULD be triggered by material changes to vendor services, security incidents, or significant changes to data processed.

16.5 Data Minimization with Third Parties

Aventora MUST limit data shared with third-party providers to the minimum necessary to perform the contracted function. Customers SHOULD evaluate enabled integrations against their own data handling requirements.

AWS provides physical security controls for infrastructure hosted in AWS data centers. Aventora remains responsible for securing configurations, access, applications, and data within its AWS environments under the shared responsibility model.

---

17. Customer Data

This section summarizes Aventora’s commitments regarding customer information. Detailed privacy requirements are in the Personal Data Privacy & Protection Policy.

17.1 Purpose Limitation and Minimization

Aventora processes only the minimum customer information required to provide contracted services. Data collection and retention MUST align with product design, customer configuration, and applicable agreements.

17.2 Customer Ownership

Customer data remains owned by the customer. Aventora processes customer data as a service provider and/or data processor according to the applicable agreement, not as the owner of the underlying business information.

17.3 Access Limitations

Access to customer data is limited to authorized Aventora personnel who require such access to operate, secure, support, or improve the services as permitted by contract. Access MUST follow least privilege and need-to-know principles.

Aventora does not access customer environments beyond authorized permissions granted by the customer and contractual terms.

17.4 No Sale of Customer Data

Aventora does not sell customer data. Customer information MUST NOT be used for advertising, sold to data brokers, or disclosed for purposes unrelated to delivering contracted services, except as required by law or explicitly authorized by the customer.

17.5 AI Processing

Conversation content and related metadata MAY be processed by configured AI providers during active sessions to deliver AI-powered engagement features. AI processing is limited to what is necessary for the enabled function. See Integration Security and the Subprocessor Annex.

---

18. Incident Handling

Incidents involving improper classification, data leakage, or unauthorized disclosure MUST be reported and managed promptly.

18.1 Improper Classification

If information is discovered to be misclassified (for example, Restricted data stored in an Internal repository), the discoverer MUST:

1. Report the issue to Aventora Security and the applicable Data Custodian without delay;
2. Avoid further unauthorized copying or sharing;
3. Cooperate with remediation, including reclassification, access restriction, and secure relocation; and
4. Document the finding if requested by Aventora Security.

18.2 Data Leakage

Suspected or confirmed data leakage—including accidental publication, misdirected email, unauthorized export, or exposure in logs—MUST be reported immediately to Aventora Security. Personnel MUST NOT attempt to conceal or delay reporting.

Aventora Security SHOULD assess scope, contain further exposure, preserve evidence, and coordinate notification in accordance with Incident Response and applicable legal obligations.

18.3 Unauthorized Disclosure

Unauthorized disclosure of Confidential or Restricted information to internal or external parties MUST be treated as a security incident. Response actions MAY include access revocation, credential rotation, customer notification, and corrective training.

18.4 Reporting Process

Step	Action
1. Report	Notify Aventora Security and your manager immediately upon discovery
2. Contain	Take reasonable steps to limit further exposure (for example, revoke shared links, disable compromised credentials) without destroying evidence
3. Document	Record what occurred, when, what data was involved, and who was notified
4. Investigate	Aventora Security coordinates investigation and determines notification obligations
5. Remediate	Implement corrective actions and track closure

Emergency contact: report through internal security channels designated by Aventora Security. Customer-facing security inquiries may be directed to security@aventora.ai.

---

19. Exceptions

Exceptions to this policy MUST be rare, documented, and approved based on risk assessment.

19.1 Approval Process

Personnel who require an exception MUST submit a written request to Aventora Security including:

• Description of the policy requirement to be excepted;
• Business justification and duration;
• Classification of information affected;
• Compensating controls proposed; and
• Approval from the applicable Business Owner.

Aventora Security MUST review exception requests and MAY approve, deny, or request modification.

19.2 Risk Acceptance

Approved exceptions constitute documented risk acceptance by the approving authority. Exceptions MUST include:

• Expiration date or review trigger;
• Named approver and date;
• Compensating controls; and
• Any customer notification requirements if customer data is affected.

Exceptions MUST be reviewed at least annually and upon material changes to the underlying system or data.

19.3 Emergency Exceptions

In emergencies where immediate action is required to protect life, safety, or critical system availability, personnel MAY deviate from this policy to the minimum extent necessary. Aventora Security MUST be notified as soon as practicable, and a retrospective exception record MUST be created.

---

20. Compliance

This policy supports alignment with applicable legal, regulatory, and contractual obligations. It does not, by itself, constitute compliance with any specific framework.

20.1 Personal Information Protection (Canada)

Where Aventora processes personal information subject to the Personal Information Protection and Electronic Documents Act (PIPEDA) and applicable provincial privacy laws, data handling MUST support Aventora’s obligations as a service provider, including safeguards appropriate to sensitivity, accountability, and limited collection and retention.

Default hosting in AWS Canadian regions supports data residency preferences for Canadian deployments.

20.2 European Data Protection

Where Aventora processes personal data subject to the General Data Protection Regulation (GDPR) or UK GDPR, data handling MUST support applicable processor obligations, including:

• Processing only on documented instructions from the customer;
• Implementing appropriate technical and organizational measures;
• Assisting with data subject rights where contractually required;
• Supporting subprocessor transparency; and
• Breach notification in accordance with agreements and applicable law.

Cross-border transfers MUST follow mechanisms recognized under applicable law where required.

20.3 Applicable Contractual Obligations

Customer agreements, data processing addenda, statements of work, and security schedules MAY impose requirements exceeding this policy. Where contractual obligations are more stringent, the contractual requirements MUST take precedence for the affected customer deployment.

20.4 Future Compliance Initiatives

Control themes in this policy are designed to support future assessment against common frameworks (for example, SOC 2 and ISO 27001). Aventora does not represent that adherence to this policy alone satisfies any certification or audit requirement.

---

21. Policy Violations

Violations of this policy MAY result in disciplinary action, contract termination, and legal consequences.

21.1 Reporting Violations

Personnel who observe or suspect policy violations MUST report them to Aventora Security or their manager. Reports SHOULD be made in good faith. Aventora MUST NOT retaliate against personnel who report suspected violations in good faith.

Willful or negligent mishandling of Restricted information, unauthorized disclosure of customer data, or bypassing security controls MUST be escalated immediately.

21.2 Corrective Actions

Corrective actions MAY include, depending on severity:

• Mandatory retraining on data classification and handling;
• Revocation of access privileges;
• Remediation of affected systems and data;
• Customer notification where required;
• Disciplinary action up to and including termination of employment or contract; and
• Referral to law enforcement where applicable.

Aventora Security SHOULD track significant violations and recurring patterns to identify systemic control gaps.

---

22. Review

22.1 Annual Review

This policy MUST be reviewed at least annually by Aventora Security to ensure continued alignment with business operations, technology changes, regulatory developments, and customer expectations.

22.2 Review After Significant Changes

An out-of-cycle review MUST be conducted upon:

• Material changes to platform architecture, hosting regions, or subprocessors;
• Introduction of new product capabilities that change data types or classifications;
• Significant security incidents involving data mishandling;
• Changes to applicable laws or contractual templates affecting data handling; and
• Findings from enterprise customer security assessments that require policy updates.

22.3 Version Control

Approved changes MUST be documented in the Version History. Personnel MUST be notified of material changes through appropriate internal communication channels. Customer-shareable versions SHOULD be made available upon request or through agreed customer documentation channels.

---

23. Version History

Version	Date	Author	Summary
1.0.1	July 27, 2026	Aventora Security	Linked Information Security Risk Management Policy and Risk Assessment and Treatment Procedure
1.0	July 6, 2026	Aventora Security	Initial release

---

Changelog

Date	Change
2026-07-27	Linked Information Security Risk Management Policy and Risk Assessment and Treatment Procedure.
2026-07-06	Public-doc hardening: classification Public / Customer Shareable; softened hosting language; stronger encryption, logging, and retention wording; security@ contact.
2026-07-06	Initial publication of Data Classification and Handling Policy v1.0.