Aventora Secure Development Lifecycle (SDLC) Policy
| Field | Value |
|---|---|
| Document Name | Secure Development Lifecycle (SDLC) Policy |
| Version | 0.9 |
| Status | Draft — Pending Management Approval |
| Effective Date | Upon formal management approval |
| Planned Approval Date | December 31, 2026 |
| Last Reviewed | July 20, 2026 |
| Policy Owner | Information Security Officer / CTO |
| Approver | [To be completed upon formal approval] |
| Review Frequency | Annually, and upon material changes to development, release, or deployment practices |
| Classification | Internal / Customer Shareable |
Document Control
This policy establishes Aventora Inc. (“Aventora,” “we,” “us,” or “our”) requirements for secure software development, review, testing, change control, and production release across Aventora platforms and supporting infrastructure.
This document describes practices currently followed in Aventora engineering and operations, and identifies where formal governance, ownership, review cadence, and approval are planned for completion by December 31, 2026. It is intended for enterprise customers, security assessors, procurement teams, and Aventora personnel.
Aventora does not claim formal certification or attestation under SOC 2, ISO 27001, or other frameworks based on this document alone. Implementation details may vary by product, hosting model (managed cloud, customer self-hosted Docker, or private cloud), contractual terms, and enabled features.
Control Maturity Legend
To avoid overstating Aventora’s posture, this policy distinguishes control maturity as follows:
| Maturity | Meaning |
|---|---|
| Implemented | Control is in regular operational use across applicable products or environments |
| Risk-based / as needed | Control is performed for material, high-risk, or security-sensitive changes, or when risk assessment indicates it is warranted — not necessarily for every change |
| Planned for formalization | Practice may already occur informally; documented ownership, cadence, approval, or enforcement is targeted for completion by December 31, 2026 |
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 | [To be completed upon formal approval] | ||
| Information Security Officer / CTO (Policy Owner) | [To be completed upon formal approval] | ||
| Engineering Leadership | [To be completed upon formal approval] |
This policy becomes effective upon signature by the Policy Owner and notification to affected personnel. Until formal approval, this document is published as a Draft — Pending Management Approval for enterprise review transparency. Material revisions require re-approval and updated version history.
Table of Contents
- Purpose
- Scope
- Policy Statement
- Roles and Responsibilities
- Security Requirements and Planning
- Secure Architecture and Design Review
- Threat and Risk Assessment
- Source Code Management
- Branch Protection and Access Control
- Secure Coding Practices
- Peer Review and Management Oversight
- Open-Source and Third-Party Dependency Management
- Secrets and Credential Management
- Development, Test, Staging, and Production Separation
- Test Data and Personal Data Handling
- Security Testing
- Vulnerability Identification and Remediation
- Change Management and Release Approval
- Build and Deployment Controls
- Production Access Restrictions
- Logging, Monitoring, and Auditability
- Emergency Changes and Rollback
- Security Defects and Incident Escalation
- Exceptions
- Training and Awareness
- Compliance and Enforcement
- Policy Maintenance and Review
- Related Policies and Standards
1. Purpose
The purpose of this Secure Development Lifecycle (SDLC) Policy is to define how Aventora designs, builds, reviews, tests, releases, and operates software securely.
This policy:
- Establishes security expectations across the software development lifecycle for Engagement Hub, Domain Assistant, Aventora CRM, administrative applications, mobile clients, and supporting infrastructure;
- Documents practices currently followed by engineering and operations teams;
- Clarifies which controls are implemented routinely, which are applied based on risk, and which are planned for formal governance by the end of 2026;
- Provides a common reference for enterprise security assessments and vendor due diligence; and
- Complements the Application Change Management Policy, API Security Policy, and Vulnerability Management documentation.
2. Scope
2.1 In Scope
This policy applies to:
| Area | Description |
|---|---|
| Software products | Engagement Hub, Domain Assistant, Aventora CRM, administrative applications (aventora-admin), marketing surfaces, and Aventora Hub mobile clients |
| APIs and integrations | REST, GraphQL, WebSocket, webhook, and server-to-server interfaces developed or operated by Aventora |
| Infrastructure as code and deployment artifacts | Dockerfiles, Docker Compose stacks, reverse proxy configuration templates, deployment scripts, and environment configuration templates |
| Personnel | Employees, contractors, and authorized agents who design, develop, review, test, deploy, or operate Aventora software |
| Deployment models | Aventora-managed cloud, customer self-hosted Docker, and private-cloud or on-premises configurations supported by Aventora |
Customer-managed systems outside Aventora’s direct control remain the customer’s responsibility unless explicitly covered by a services agreement.
2.2 Enterprise and Pilot Deployments
Where contractually agreed for enterprise customers or controlled pilots, Aventora MAY apply additional controls such as:
- Dedicated hosting environments and region selection;
- Data minimization in product features, logging, and integrations; and
- Environment isolation separating customer pilot workloads from unrelated production tenants or non-production systems.
These measures are applied where applicable to the engagement and are documented in deployment plans or customer-specific security materials. They do not imply identical isolation for every Aventora deployment.
2.3 Out of Scope
Unless explicitly addressed in a written agreement, the following remain outside this policy:
- Customer-developed customizations and systems not operated by Aventora;
- Third-party products configured solely by the customer outside Aventora’s control; and
- General employee use of consumer productivity tools, which is governed by separate acceptable-use and confidentiality requirements.
3. Policy Statement
Aventora SHALL integrate security into the software development lifecycle so that changes are version-controlled, reviewed, tested, and released with proportionate security controls.
Aventora personnel MUST:
- Maintain software and infrastructure configuration in private version-controlled repositories;
- Apply role-based access and least privilege to source code, cloud, and production systems;
- Use multi-factor authentication for GitHub, AWS, and Google accounts used for development and operations;
- Avoid hard-coding production credentials in source code or container images;
- Perform peer review for material changes and security-focused review for security-sensitive changes;
- Validate changes before production deployment using applicable testing and pre-deploy checks; and
- Prioritize vulnerability remediation based on risk, likelihood, and business impact.
Formal SDLC governance—including documented ownership, approval authority, and review cadence for this policy—is planned for formalization by December 31, 2026. Until then, Engineering Leadership and the Information Security Officer / CTO jointly oversee secure development practices described in this draft.
4. Roles and Responsibilities
| Role | Responsibilities | Maturity |
|---|---|---|
| Information Security Officer / CTO | Owns this policy; defines security expectations for the SDLC; approves material security exceptions; coordinates formalization and annual review | Implemented ownership; formal approval process planned for formalization |
| Engineering Leadership | Approves production deployments for Aventora-managed environments; approves high-risk and security-sensitive changes; defines quality expectations for release promotion | Implemented |
| Developers | Implement changes in version control; follow secure coding practices; submit material changes for peer review; run applicable tests and security scan utilities before production promotion; document configuration and migration impacts | Implemented |
| DevOps / System Administrators | Build, tag, and promote container images; apply infrastructure and Compose changes; restrict production host and environment-file access; execute rollouts and rollbacks; coordinate emergency changes | Implemented |
| Reviewers | Evaluate correctness, security impact, and data-handling implications of pull requests before merge to shared branches | Implemented for material changes |
| All personnel with privileged access | Protect credentials; report security defects and suspected incidents; complete applicable security awareness activities | Implemented / risk-based |
Until formally designated, the Information Security Officer function MAY be fulfilled by the CTO or other qualified personnel designated by management.
5. Security Requirements and Planning
Security requirements SHOULD be considered during feature planning and design, especially for changes affecting authentication, authorization, public endpoints, secrets, personal data, or third-party integrations.
| Expectation | Maturity |
|---|---|
| Security and privacy considerations incorporated into design and release for data-handling changes | Implemented (risk-based depth) |
| New public endpoints require Engineering Leadership approval and documented compensating controls | Implemented |
| New third-party integrations require Engineering Leadership approval before production use | Implemented |
| Formal security requirements checklists and gated planning workflows for all features | Planned for formalization |
Related requirements appear in the Personal Data Privacy & Protection Policy and Data Classification and Handling Policy.
6. Secure Architecture and Design Review
Material architecture changes—including new trust boundaries, authentication models, data stores, or cross-service integrations—MUST receive engineering review before production use.
| Practice | Maturity |
|---|---|
| Engineering review of material architecture and integration changes | Implemented (risk-based) |
| Alignment with existing authentication, authorization, and tenant-isolation patterns | Implemented |
| Formal architecture review board or mandatory design-review checklist for every change | Planned for formalization |
Engineers SHOULD consult API Security Model when adding cross-service integrations to preserve least-privilege credential patterns.
7. Threat and Risk Assessment
Aventora assesses security risk for material changes based on exposure, data sensitivity, exploitability, and business impact.
| Practice | Maturity |
|---|---|
| Risk-informed review depth for security, infrastructure, and data-handling changes | Implemented |
| Remediation prioritization by severity, likelihood, and business impact | Implemented |
| Formal threat-modeling methodology and documented threat models for every product release | Planned for formalization / risk-based as needed |
Threat and risk assessment depth MAY increase for enterprise pilots, dedicated hosting deployments, or changes affecting personal information.
8. Source Code Management
| Requirement | Practice | Maturity |
|---|---|---|
| Version control | All software and infrastructure-as-code changes MUST be maintained in version control | Implemented |
| Private repositories | Product source code is maintained in private GitHub organization repositories | Implemented |
| Traceability | Commits, pull requests, and merge history provide an auditable record of what changed, when, and by whom | Implemented |
| No secrets in repositories | Live credentials MUST NOT be committed; sample and template environment files use non-sensitive placeholders | Implemented |
Aventora does not currently maintain a centralized change-management ticketing system as a mandatory prerequisite for every commit. Traceability relies primarily on GitHub history, deployment artifacts, and operational records. See the Application Change Management Policy.
9. Branch Protection and Access Control
| Control | Practice | Maturity |
|---|---|---|
| Role-based access | Repository and organization access uses role-based permissions with least privilege | Implemented |
| MFA | MFA is required for Aventora personnel on GitHub, AWS, and Google accounts used for development and operations | Implemented |
| Feature branches | Engineers use feature branches where appropriate for non-trivial work and merge to shared integration branches (for example, main) through pull requests | Implemented |
| Protected shared branches | Material changes to shared branches proceed through pull request review workflows | Implemented |
| Uniform enforced branch-protection rules across all repositories | Organization-wide standardized protection settings and required status checks for every repository | Planned for formalization |
Access to production deployment hosts and environment files is further restricted as described in Section 20.
10. Secure Coding Practices
Development teams MUST apply secure coding practices appropriate to the technology stack and risk of the change.
Minimum expectations:
- Server-side input validation and authorization checks on sensitive routes;
- Avoid logging secrets, credentials, or excessive personal information;
- Prefer additive, backward-compatible API changes where practical;
- Use framework and platform security patterns already established in each product;
- Document security-relevant configuration for new features.
| Practice | Maturity |
|---|---|
| Secure coding expectations for authentication, authorization, validation, and data handling | Implemented |
| Formal secure coding standard with mandatory training attestation for all engineers | Planned for formalization |
For API-specific requirements, see the API Security Policy.
11. Peer Review and Management Oversight
| Requirement | Practice | Maturity |
|---|---|---|
| Peer review | Material code changes are reviewed by engineering personnel other than the author before merge to shared branches | Implemented |
| Security review | Changes affecting authentication, authorization, public endpoints, webhook handlers, secrets, cross-service trust boundaries, or customer data handling receive explicit security consideration during review | Implemented (risk-based) |
| Management oversight | Engineering Leadership approves production deployments and high-risk changes for Aventora-managed environments | Implemented |
| Documented security review checklist for every pull request | Standardized security review checklist enforced on all repositories | Planned for formalization |
Reviewers evaluate correctness, security impact, and compatibility with existing authentication, authorization, and data-handling patterns.
12. Open-Source and Third-Party Dependency Management
| Practice | Maturity |
|---|---|
Dependency manifests (requirements.txt, package.json, and equivalents) updated through version-controlled changes | Implemented |
Dependency audits via repository security scan utilities (pip-audit for Python services, npm audit for Node-based applications) before production promotion where scans are executed | Implemented (engineer-initiated) |
| High-severity dependency findings remediated or documented with an approved remediation plan before production promotion where scans are executed | Implemented |
| Continuous automated dependency scanning enforced in CI on every pull request across all products | Planned for formalization |
Third-party service integrations (telephony, AI, identity, calendar, and related providers) require Engineering Leadership approval before production use and are documented in the Subprocessor Annex and Integration Security.
13. Secrets and Credential Management
| Requirement | Practice | Maturity |
| --- | --- |
| No hard-coded production credentials | Production secrets MUST NOT be embedded in source code or baked into image layers | Implemented |
| Environment-based secrets | Runtime secrets and configuration are supplied via host-managed environment files and Compose env_file injection (or equivalent deployment configuration) | Implemented |
| Restricted access | Production environment files and secret stores are accessible only to authorized operations personnel | Implemented |
| Credential protection in applications | API keys and passwords use industry-standard hashing or equivalent protections appropriate to the credential type | Implemented |
| Rotation | Secrets suspected or confirmed compromised are rotated promptly | Implemented (as needed) |
| Centralized vault services | Vault or managed secret injection MAY be used depending on deployment model | Risk-based / deployment-specific |
Sample and template configuration files MUST use non-sensitive placeholders. Pre-commit and CI secret scanning SHOULD be used to prevent accidental secret commits where tooling is available.
14. Development, Test, Staging, and Production Separation
Aventora separates non-production and production concerns to reduce operational and data risk.
| Practice | Maturity |
|---|---|
| Distinct credentials and configuration for development versus production | Implemented |
| Validation in development or staging environments where applicable before production promotion | Implemented (product-dependent) |
| Staging and test endpoints for selected managed services | Implemented for selected services |
| Dedicated long-lived staging stack for every product in every deployment model | Not uniformly available; improvement area |
| Dedicated hosting and environment isolation for enterprise pilots where contractually agreed | Implemented where applicable |
Not every product has a dedicated long-lived staging stack in every deployment model. Customer self-hosted deployments MAY validate against local or customer-provided non-production instances before applying updates to production Compose stacks.
15. Test Data and Personal Data Handling
| Requirement | Practice | Maturity | | --- | --- | | Production customer data MUST NOT be used in development, testing, or staging without explicit authorization | Implemented (policy requirement) | | Prefer synthetic, masked, or anonymized data for testing | Implemented (risk-based) | | Data minimization in features, logging, and integrations | Implemented | | Enterprise pilot data minimization and environment isolation where contractually required | Implemented where applicable |
Authorized use of production data in non-production environments MUST be logged and deleted when the approved purpose is complete. See Data Classification and Handling Policy — Development Environment Requirements.
16. Security Testing
Security testing expectations vary by product and change type.
| Activity | Practice | Maturity | | --- | --- | | Functional testing | Developers validate changed behavior locally or in shared development environments before merge; manual verification for affected user-facing and operational workflows | Implemented | | Automated unit / integration tests | Available for applicable packages (for example, CRM monorepo test targets); used where implemented for the changed component | Implemented (product-dependent) | | Repository security scan utilities | Static analysis including dependency audit, secret detection, SAST where applicable, and custom configuration checks for core platform repositories (Domain Assistant, Engagement Hub, and admin dashboard) | Implemented (engineer-initiated before release promotion) | | Pre-deploy validation | Engagement Hub preflight checks (for example, Python compilation and smoke imports) before production service restarts | Implemented where applicable | | Live security probes | Optional auth regression, webhook abuse, and CORS validation against localhost or confirmed staging targets following documented safety rules | Risk-based / as needed | | Continuous automated enforcement of all scan types in CI on every pull request | Ongoing improvement area | Planned for formalization | | Scheduled third-party penetration testing cadence | Not claimed as a standing program in this policy | Risk-based / as needed; not a standing commitment |
Findings at high severity or above are remediated before release where scans are executed, or documented with Engineering Leadership approval and compensating controls. See Vulnerability Management.
17. Vulnerability Identification and Remediation
Aventora identifies vulnerabilities through dependency audits, security scan utilities, code review, operational monitoring, and external reports to security@aventora.ai.
Remediation is prioritized by severity, likelihood, exploitability, and business impact:
| Severity | Response expectation | Maturity | | --- | --- | | Critical | Immediate assessment and remediation; emergency change process if required | Implemented | | High | Remediation before next production release or documented compensating controls | Implemented | | Medium | Scheduled remediation within normal release activity | Implemented | | Low | Tracked and addressed as part of routine maintenance | Implemented |
Aventora does not claim that every dependency vulnerability is automatically blocked by CI gates across all repositories. Where scans are executed before promotion, high-severity findings are addressed or explicitly accepted with compensating controls.
18. Change Management and Release Approval
Releases are executed based on business and operational needs rather than a fixed public release calendar. Ad hoc releases are normal when justified by product delivery, security remediation, or operational requirements.
| Practice | Maturity |
|---|---|
| Version-controlled change tracking via GitHub history and deployment artifacts | Implemented |
| Engineering Leadership (or designated leads) authorization for production deployments in Aventora-managed environments | Implemented |
| Additional review for security, infrastructure, authentication, public API, data retention, and new vendor integration changes | Implemented (risk-based) |
| Documented change classification (standard, emergency, security, infrastructure, configuration) | Implemented — see Application Change Management Policy |
| Centralized change ticket required for every production deployment | Not currently required across all products |
Customer-managed deployments follow the same version-controlled release artifacts; the customer or their operations team executes deployment on their infrastructure using Aventora-provided images, Compose files, and runbooks.
19. Build and Deployment Controls
Aventora products are deployed primarily as Docker-based containerized services.
| Control | Practice | Maturity | | --- | --- | | Automated build and deployment processes | Container images are built from Dockerfiles; Compose-based deployment and image promotion workflows are used for production hosts | Implemented | | Versioned releases | Production images use versioned tags (for example, date-based or semantic tags); CRM supports build-and-push workflows with explicit tag promotion | Implemented | | Configuration injection | Runtime secrets supplied via environment configuration — not baked into image layers | Implemented | | Controlled rollout | Deployments executed according to product runbooks; preflight and security checks completed before restarts where applicable | Implemented | | Immutable infrastructure rebuilds | Running containers replaced with new image versions rather than modified in place | Implemented |
20. Production Access Restrictions
| Requirement | Practice | Maturity | | --- | --- | | Least privilege | Production host, database, and environment-file access restricted to authorized personnel | Implemented | | MFA for privileged platforms | MFA required for GitHub, AWS, and Google accounts used for development and operations; administrative portal MFA supported and enforced where configured | Implemented | | Role-based access | Platform and administrative authorization uses RBAC and server-side enforcement | Implemented | | No routine developer production write access | Day-to-day development uses non-production environments; production changes follow deployment and approval practices | Implemented (risk-based exceptions for operations) |
Direct production changes outside normal deployment paths are limited to authorized emergency procedures (Section 22).
21. Logging, Monitoring, and Auditability
| Mechanism | Description | Maturity |
| --- | --- |
| GitHub history | Commits, branches, pull requests, and merges provide source-change auditability | Implemented |
| Deployment artifacts | Versioned container tags, Compose deployment activity, and operational runbooks document what was deployed | Implemented |
| Application and system logs | Security-relevant authentication, authorization, and operational events support investigation | Implemented |
| Security scan reports | Reports stored when generated (for example, under local reports/security/ paths) document findings for releases where scans are executed | Implemented (when scans run) |
| Centralized immutable change ledger / mandatory change tickets | Not currently maintained across all products | Planned for formalization as needed |
Logging and monitoring expectations are further described in Logging and Audit.
22. Emergency Changes and Rollback
Emergency changes are permitted when necessary to restore service, contain an active security incident, or mitigate imminent operational risk.
| Requirement | Practice | Maturity | | --- | --- | | Expedited deployment without standard lead time when justified | Implemented | | Post-implementation review and documentation (what changed, who authorized, when, residual risk) | Implemented | | Backport of direct production fixes to version control as soon as practicable | Implemented | | Rollback via previous image tags and version-controlled configuration | Implemented |
Database migrations are planned with backward-compatibility considerations; emergency rollback involving schema changes MAY require Engineering Leadership guidance.
For related incident handling, see Incident Response.
23. Security Defects and Incident Escalation
| Path | Expectation | Maturity | | --- | --- | | Internal security defects | Engineers report security defects to Engineering Leadership and the Information Security Officer / CTO; high-severity issues are treated as priority remediation | Implemented | | External vulnerability reports | Reports accepted at security@aventora.ai | Implemented | | Security incidents | Escalated through Aventora’s incident response procedures, including containment, investigation, and customer notification where required | Implemented | | Formal defect SLA matrix published for all severity levels | Severity response expectations exist in vulnerability management materials; formal SLA publication may be refined | Planned for formalization |
Security defects that indicate active compromise or customer data exposure MUST be escalated immediately under the Incident Response process.
24. Exceptions
Exceptions to this policy MUST be approved by the Information Security Officer / CTO (or designee) and, for production risk acceptance, Engineering Leadership.
Exception requests SHOULD document:
- The control that cannot be met;
- Business justification and duration;
- Compensating controls; and
- Residual risk and planned remediation.
Exceptions are time-bound where practical and reviewed during policy maintenance.
25. Training and Awareness
| Expectation | Maturity |
|---|---|
| Engineering and operations personnel are expected to follow secure development, secrets handling, and incident reporting practices described in Aventora security documentation | Implemented |
| Security awareness communicated through policies, runbooks, and engineering guidance | Implemented |
| Formal SDLC training curriculum with attendance tracking for all developers | Planned for formalization |
Personnel with privileged access SHOULD remain familiar with this policy, the Application Change Management Policy, and related security standards.
26. Compliance and Enforcement
Failure to follow this policy may result in revocation of repository or production access, required remediation, and other actions consistent with Aventora employment or contractor agreements.
This policy supports alignment with common enterprise control themes (including secure development, change management, least privilege, and vulnerability management) without asserting certification status. See Compliance.
Questions regarding this policy may be directed to security@aventora.ai.
27. Policy Maintenance and Review
| Activity | Expectation | Maturity | | --- | --- | | Ownership | Information Security Officer / CTO owns this policy | Implemented (draft ownership) | | Review frequency | At least annually, and upon material changes to development, release, hosting, or product architecture | Planned for formalization of cadence and records | | Formal management approval | Targeted for completion by December 31, 2026 | Planned for formalization | | Version history | Material revisions recorded in Version History below | Implemented for this draft |
Until formal approval, this document remains Draft — Pending Management Approval. Practices described as Implemented remain in operational use; governance formalization continues through the planned approval date.
28. Related Policies and Standards
| Document | Relationship |
|---|---|
| Security Overview | Platform security commitments and control summary |
| Customer Security Package | Index of customer-shareable security documentation |
| Application Change Management Policy | Change classification, testing, approval, deployment, emergency changes, and auditability |
| API Security Policy | API authentication, authorization, secure development, and integration security |
| Vulnerability Management | Vulnerability identification, severity response, and reporting |
| Information Security Risk Management Policy | Application and change-related risk tracking |
| Risk Assessment and Treatment Procedure | Risk scoring and treatment methodology |
| Authentication | Identity, MFA, and access control practices |
| Logging and Audit | Logging and monitoring expectations |
| Incident Response | Security incident handling |
| Data Classification and Handling Policy | Classification, handling, and development-environment data rules |
| Personal Data Privacy & Protection Policy | Privacy-by-design and secure development for personal information |
| AI Governance Policy | Responsible AI development and provider governance |
| Integration Security | Third-party integration security controls |
| Compliance | Control theme alignment (non-certification) |
| Subprocessor Annex | Third-party processors |
Alignment with industry guidance
This policy addresses control themes commonly evaluated in enterprise security programs without asserting formal certification:
| Guidance | Relationship |
|---|---|
| SOC 2 | Secure development, change management, access control, and vulnerability management themes are reflected in the practices described here |
| ISO 27001 principles | Controlled change, segregation of environments, and least privilege align with common ISMS expectations; a formal ISMS is not claimed |
| OWASP | Secure coding, dependency management, and pre-release security validation align with OWASP software assurance guidance |
Version History
| Version | Date | Author / Owner | Summary of Changes |
|---|---|---|---|
| 0.9.1 | July 27, 2026 | Information Security Officer / CTO | Linked Information Security Risk Management Policy and Risk Assessment and Treatment Procedure |
| 0.9 | July 20, 2026 | Information Security Officer / CTO | Initial draft of Secure Development Lifecycle (SDLC) Policy published for enterprise review; status Draft — Pending Management Approval; formal approval targeted for December 31, 2026 |
Contact
For questions regarding this policy, secure development practices, or security questionnaires:
- Security and privacy: security@aventora.ai
- Commercial and onboarding: sales@aventora.ai
This document is provided for informational and contractual support purposes. It does not constitute legal advice. Until formally approved, it is a draft pending management approval.