Security & Trust Overview

Last Updated: [Last Updated Date]
Effective Date: [Effective Date]

Draft notice. This document is provided for informational purposes and as a high-quality starting draft. It does not constitute legal advice. Axiogen's actual policies and agreements must be reviewed, customized, and approved by qualified legal counsel licensed in the relevant jurisdictions before publication or use. Every control described below must be confirmed as implemented by Axiogen's security lead before publication; bracketed items are unconfirmed.

1. Our commitment

Axiogen AI ("Axiogen") is trusted by pharmaceutical and medical-device companies with their commercial data, their field activity, and their compliance records. Our customers' legal, privacy, and security teams hold us to the standard they apply to any system that touches healthcare-professional data and regulated promotional activity — and we design to that standard.

This page describes how we protect the Axiogen platform, API, and the data within them. It is written for security, privacy, and procurement reviewers. It deliberately describes controls at a level that is useful for assurance without publishing details that would help an attacker; the full Security Packet, with evidence, is available to customers and qualified prospects under NDA (Section 14).

Our approach rests on six commitments:

Customer data is isolated and never shared. Each customer's content is logically separated, and no customer's content is ever used to train models that serve another customer.
Least privilege, everywhere. Access to data — by customers' users and by our own personnel — is scoped to role and need, and is reviewed.
Encryption is the default. All data is encrypted in transit with TLS 1.3 and at rest with AES-256.
Every action leaves a trace. An immutable audit log records user and administrative activity, which also underpins our customers' MLR and compliance workflows.
We verify rather than assume. Independent testing, continuous scanning, and [third-party attestation] check our controls.
We tell customers what they need to know, quickly. Security incidents affecting customer data are notified within contractual timelines, with the detail customers need to meet their own obligations.

2. Certifications and attestations

[ATTESTATION STATUS — confirm before publishing; choose one.]

If a SOC 2 Type II report has been issued: Axiogen maintains a SOC 2 Type II attestation covering the [Security, Availability, and Confidentiality] Trust Services Criteria for the Axiogen platform, issued by [Audit Firm] for the period [dates]. The report is available under NDA — see Section 14.

If not yet issued: Axiogen's security program is designed and operated against the AICPA SOC 2 Trust Services Criteria. A SOC 2 Type II examination is [in progress / scheduled for [date]] with [Audit Firm]; until the report is issued, Axiogen does not represent itself as SOC 2 attested. Customers may review our control documentation and independent penetration-test summaries under NDA in the meantime.

Frameworks we align to. Beyond SOC 2, our controls are mapped to the HIPAA Security Rule safeguard standards (see HIPAA & Business Associate Information) and to the GDPR's Article 32 security requirements (see the Data Processing Addendum, Annex II). [If applicable: we also maintain a mapping to ISO/IEC 27001:2022 Annex A controls; we do not hold ISO certification unless stated here.]

Our hosting providers' certifications. The platform runs on [Cloud Provider], whose infrastructure is independently audited against SOC 1/2/3, ISO/IEC 27001, 27017, and 27018, PCI DSS, and other frameworks. Those certifications cover the physical and infrastructure layers; Axiogen's own program covers the platform, application, and data layers built on top of them.

We will not list a certification we do not hold. If you need an attestation that is not listed, tell us — it helps us prioritize our roadmap.

3. Organization and governance

Accountability. Security is owned by [Title — e.g., Head of Security / CTO], who reports to the CEO and briefs the board [quarterly]. Privacy is owned by [Data Protection Officer / Privacy Lead]. The two functions meet [weekly] and share a single risk register.
Policies. We maintain a written information security policy set covering access control, acceptable use, data classification and handling, change management, vulnerability management, incident response, business continuity, vendor management, secure development, and AI use. Policies are reviewed and approved at least annually and on significant change.
Risk management. We perform a formal risk assessment at least annually and when the platform, threat landscape, or regulatory environment changes materially. Risks are tracked to owners and remediation dates.
People. All personnel sign confidentiality agreements, complete security and privacy training at onboarding and at least annually, and receive role-specific training (for example, secure coding for engineers). Background checks are performed for personnel with production access, where permitted by law. Access is revoked on the day of departure.
Data classification. Data is classified as Public, Internal, Confidential, or Restricted; Customer Content and Axiogen Data are Restricted and Confidential respectively, with handling rules for each.

4. Identity and access management

For customers' users

Single sign-on via SAML 2.0 with the customer's identity provider, so that the customer's own authentication policies — including multi-factor authentication, device trust, and conditional access — govern access to Axiogen.
SCIM provisioning for automated creation, update, and deactivation of user accounts from the customer's directory, so that joiners, movers, and leavers are handled without manual steps.
Role-based access control with customer-configurable roles (for example, administrator, analyst, field representative, medical, compliance reviewer).
Row-level access controls that scope what each user can see — by tenant, and within a tenant by territory, team, or data domain — enforced at the data layer, not only in the user interface.
Session management with configurable timeouts and the ability for administrators to terminate sessions.
API keys scoped per integration, with rotation and revocation, and rate limiting by key.

For Axiogen personnel

SSO and hardware-backed multi-factor authentication for all internal systems.
Production access restricted to a small, named group; privileged operations require [just-in-time elevation / approval] and are logged.
Access to customer content by Axiogen personnel is limited to what is required for support and operations, is logged in the audit trail, and is reviewed [quarterly].
No standing access to production databases from developer workstations.

5. Encryption and key management

In transit: TLS 1.3 for all connections to the platform and API, with HSTS enforced. Internal service-to-service traffic is encrypted.
At rest: AES-256 encryption for all databases, object storage, search indexes, and backups.
Keys: Managed through [Cloud Provider]'s key-management service with hardware-backed roots, strict access policies, automatic rotation, and audit logging of key use. [If offered: customer-managed keys available on enterprise plans.]
Secrets: Application secrets and credentials are stored in a dedicated secrets manager, injected at runtime, and never committed to source control; automated scanning prevents accidental commits.

6. Network and infrastructure security

Hosting. The platform is hosted with [Cloud Provider] in the United States [with an additional [EU / other] region available for customers that require it — confirm]. We use multiple availability zones for core services.
Segmentation. Production runs in private networks; data stores have no public endpoints and accept connections only from authorized application tiers. Development, staging, and production environments are fully separated.
Perimeter. A web application firewall and DDoS protection front all public endpoints. Firewall and security-group rules follow least access and are managed as code with peer review.
Hardening. Infrastructure is defined as code, built from hardened base images, patched on a defined cadence, and continuously checked against configuration baselines.
Tenant isolation. Customer Content is logically isolated per tenant at the application and database layers; cross-tenant access is prevented by the same row-level controls that govern user access, and is tested as part of our security testing.

7. Application security and secure development

Secure SDLC. Every change goes through peer code review, automated tests, static application security testing, and software-composition analysis for vulnerable dependencies before it can be merged. Infrastructure changes follow the same path.
Secure design. New features that touch customer data, authentication, or AI behavior receive a design review that includes security and privacy considerations (threat modeling for significant changes).
Dependencies. Third-party packages are pinned, scanned continuously, and updated on a defined cadence, with critical vulnerabilities handled out of band.
Environments. Production data is not used in development or test environments except in de-identified form.
Deployment. Deployments are automated, reproducible, and rollback-capable; production changes are logged and attributable.

8. Vulnerability management and penetration testing

Continuous scanning of infrastructure, containers, and application dependencies, with findings triaged by severity.
Remediation targets by severity: [critical within [7] days, high within [30] days, medium within [90] days — confirm].
Independent penetration testing of the platform and API by a third-party firm [annually — confirm cadence] and after major architectural changes. Executive summaries are available under NDA; findings are tracked to closure.
Coordinated vulnerability disclosure. We welcome reports from security researchers at [Security Contact Email] (e.g., security@axiogen.ai). See our Contact page for scope, safe-harbor terms, and what to expect from us.

9. Logging, monitoring, and detection

Immutable audit log. User and administrative actions in the platform — logins, searches, record views, exports, outreach drafted and sent, permission changes, API calls — are written to a tamper-evident, append-only audit log. Customers can access their own audit data for MLR review, investigations, and compliance reporting. Audit records are retained for [period — confirm].
Security telemetry. Infrastructure, application, and identity logs are centralized, protected from modification, and retained for [period].
Detection and alerting. Automated rules and anomaly detection alert the on-call engineer to suspicious activity such as unusual export volumes, authentication anomalies, privilege changes, and configuration drift. [Staffing and response expectations — e.g., "24/7 on-call" — confirm before publishing.]
Review. Alerts and access logs are reviewed on a defined cadence, and detection rules are tuned after every incident and exercise.

10. Incident response

A documented incident response plan defines roles, severity levels, communication paths, evidence handling, and regulatory considerations. It is exercised at least annually through tabletop or live drills.
Customer notification. We notify affected customers of a security incident involving their data without undue delay and within the timelines in the Data Processing Addendum (Section 7) and, for PHI, the applicable Business Associate Agreement. Notifications include what happened, what data and how many records were affected as far as known, what we have done, what we recommend, and a named contact; updates follow as the investigation progresses.
Post-incident review. Every significant incident receives a blameless post-mortem with corrective actions tracked to completion, and lessons are fed back into controls and training.
Status communication. [Link to status page, if available.]

11. Business continuity and disaster recovery

Backups. Encrypted backups are taken at least daily and stored in a separate location from production; point-in-time recovery is available for primary databases.
Recovery objectives. [Recovery Point Objective: [●] hours; Recovery Time Objective: [●] hours — confirm.]
Resilience. Core services run across multiple availability zones with automated failover.
Testing. Backup restoration and disaster-recovery procedures are tested at least annually, and results are recorded.
Availability commitments. Service-level commitments, where offered, are set out in the customer's Order Form or Enterprise Agreement. [Do not publish an uptime percentage on this page unless contractually backed and measured.]

12. Vendor and sub-processor management

Every vendor that will process customer data is assessed for security and privacy before onboarding — including review of independent audit reports, security questionnaires, and data-handling practices — and reassessed on a defined cadence.
Contracts include confidentiality, security, breach-notification, and data-protection terms that flow down our obligations (see the Data Processing Addendum, Section 5).
Our current sub-processors, their purpose, and their processing location are published at [Link to current Sub-processor List]; customers can subscribe to change notifications and have an objection right.

13. AI-specific safeguards

The Axiogen platform uses machine learning and large language models for classification, scoring, relationship mapping, summarization, and drafting assistance. We apply the following safeguards:

No training on customer content for others. Customer Content is never used to train or fine-tune models that are made available to any other customer. Shared models are developed on Axiogen's own dataset, public data, licensed data, and synthetic or aggregated data.
Third-party model providers. Where we use external model APIs, they are engaged as sub-processors under terms that prohibit training on our inputs and outputs and limit retention to [zero / a short abuse-monitoring window]. They are listed on the Sub-processor List.
Permissions are inherited. AI features operate strictly within the requesting user's access permissions. A model cannot retrieve, summarize, or draft from records the user could not open themselves; row-level controls are enforced before any data reaches a model.
Provenance and traceability. Derived attributes carry provenance to their inputs, and AI-generated outputs are logged in the audit trail so that customers can see what was generated, from what, by whom, and when.
Human in the loop for outreach. The platform does not send communications to healthcare professionals autonomously. Drafted content is presented for human review, and customers' MLR-approved content libraries and off-label detection checks are applied before send. Off-label detection is a control that assists customers' compliance processes; it does not replace them.
Prompt-injection and abuse controls. Inputs derived from external content (social posts, reviews, uploaded documents) are treated as untrusted data, and models are instructed and constrained so that such content cannot alter system behavior or exfiltrate data. We test these controls as part of security testing.
Model governance. Models and prompts are versioned; significant changes are evaluated for accuracy, bias, and safety before release; and customers are informed of material changes to AI features.
No consumer-scale decisions. Platform outputs are decision-support for trained commercial and medical personnel. They are not used to make decisions with legal or similarly significant effects on individuals, and our Terms of Service prohibit such uses.

14. Requesting our Security Packet

Customers and qualified prospects can request the following under NDA:

[SOC 2 Type II report — if issued] or current control documentation
Most recent penetration-test executive summary
Completed security questionnaires (SIG Lite / CAIQ / custom)
Security policy summaries and architecture overview
HIPAA Security Rule control mapping
Business continuity and incident response plan summaries
Sub-processor list with transfer mechanisms

How to request: email [Security Contact Email] (e.g., security@axiogen.ai) or use [Link to request SOC 2 report under NDA]. Existing customers can also ask their account manager. We aim to respond within [2] business days.