Security & Trust

Healthcare-grade security by design.

AEGIS ISD is designed to process Protected Health Information for health plans, state Medicaid agencies, and commercial health insurers under executed Business Associate Agreements. Our security program is built around the SOC 2 Trust Services Criteria, the HIPAA Security Rule, and the ISO/IEC 27001 Information Security Management System framework.

Last updated: April 24, 2026

Compliance posture

Attestations and frameworks.

We pursue a broad-scope compliance program and avoid treating in-progress audits as completed certifications. Issued reports and approved audit artifacts are available to qualified customers and prospects under a mutual non-disclosure agreement by emailing legal@aegisisd.com.

SOC 2 Type II

In progress with AtomAudits, scoped to all five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. No SOC 2 report has been issued yet. Controls evidence is collected through Sprinto and surfaced to the auditor across the observation window.

HIPAA

AEGIS ISD acts as a Business Associate to covered-entity customers when processing PHI and maintains safeguards designed to support the applicable requirements of the HIPAA Security Rule and Breach Notification Rule, and the Privacy Rule obligations that apply to Business Associates under 45 CFR ยงยง164.502 and 164.504(e). Our policy is to enter into a BAA with each customer before processing PHI, and with each subcontractor that may process PHI on our behalf. See our HIPAA page.

ISO/IEC 27001

On roadmap. We maintain an Information Security Management System (ISMS) mapped to the 2022 revision of Annex A controls and plan to pursue formal certification through an accredited registrar after our initial SOC 2 Type II observation period.

SOC 2 Trust Services Criteria

How we cover all five TSCs.

Security

  • TLS 1.2 or higher for all data in transit; AES-256 for data at rest.
  • SSO / SAML single sign-on and multi-factor authentication for administrative access.
  • Role-based access with least-privilege and periodic access reviews.
  • Centralized audit logging across platform, infrastructure, and identity layers.
  • Schema-per-tenant data isolation; no shared row-level tables for customer data.
  • External penetration testing on a regular cadence; vulnerability scanning.
  • Documented incident response plan with defined roles and exercise program.

Availability

  • Service-level commitments set forth in each customer order form.
  • Automated backups with restore testing on a regular cadence.
  • Recovery-time and recovery-point objectives (RTO / RPO) defined in customer order forms or service documentation.
  • Documented disaster recovery plan, with failover procedures exercised on a regular cadence.
  • Capacity planning and performance monitoring.
  • Incident root-cause analysis; customer-facing reports for qualifying events.

Confidentiality

  • Data classification policy distinguishing Public, Internal, Confidential, and Restricted data.
  • Encryption applied to Confidential and Restricted data at rest and in transit.
  • Contractual confidentiality obligations with vendors, employees, and contractors.
  • Secure media disposal aligned with NIST SP 800-88 Rev 1 guidance.

Processing Integrity

  • Input validation and schema enforcement on ingestion points.
  • Completeness and accuracy controls on case, claim, and review workflows.
  • Reconciliations for financial outcomes and recovery tracking.
  • Documented error-handling and data-correction procedures.
  • Audit trails on workflow state transitions.

Privacy

  • Marketing-site handling of information is described in our Privacy Policy.
  • Platform handling of PHI and customer personal information is governed by the applicable BAA and order form.
  • Minimum-necessary access; role-scoped queries and masking where appropriate.
  • Documented procedures for individual-rights requests and breach notifications.

Architecture highlights

Defense in depth.

Hosting and tenancy

The platform runs on Oracle Cloud Infrastructure (OCI) in the United States. Each customer tenant is isolated in a dedicated database schema with tenant-aware query filters enforced in every data path. A current list of subprocessors is maintained at aegisisd.com/subprocessors.

Identity and access

SAML 2.0 / OIDC single sign-on, multi-factor authentication for administrative roles, role-based permissions with least-privilege defaults, and periodic access reviews for production and customer-data-adjacent systems.

Encryption and keys

TLS 1.2 or higher for all data in transit between clients, services, and storage. AES-256 encryption for data at rest across databases, object storage, and backups. Keys are managed through the cloud provider's key management service with rotation on a defined schedule.

Logging and monitoring

Centralized audit logging across application, infrastructure, and identity layers. Security events are routed to alerting for triage. PHI access logs are retained in accordance with the HIPAA Security Rule.

Secure development

Peer-reviewed code with required approvals, automated static analysis and dependency scanning in CI, segregation between development, staging, and production, and change-management tickets linked to source-control commits.

Vendor management

Vendors that may access Customer Data are onboarded with a risk-tiered due-diligence process, contractual data-protection terms, and periodic re-review. Each subprocessor that may process PHI is bound by a downstream Business Associate Agreement.

Application-layer hardening

Defense at the data path.

Beyond infrastructure controls, AEGIS ISD applies specific application-layer hardening to the boundaries where Customer Data is most exposed: query construction, asynchronous processing, and cross-tenant query enforcement.

SQL injection — parameterized table whitelist

Where the platform constructs SQL from user-supplied identifiers (for example, dynamic search and AI-generated text-to-SQL), table and column references are validated against a server-side whitelist before any query is executed. Identifiers outside the whitelist are rejected at the input layer; user-supplied values are always passed as parameters, never interpolated.

Row-level security — parameterized tenant scope

Tenant scope is enforced at the database layer through parameterized row-level security policies, not by application-side WHERE clauses alone. Every connection establishes the tenant context through a session-scoped parameter; queries that reach the database without a valid tenant parameter are rejected before reading any row.

Async tenant-context propagation

When work crosses thread boundaries — queues, scheduled jobs, async event handlers, AI invocations — the originating tenant context propagates with the work through an explicit context wrapper. Async code that would otherwise default to no tenant is structurally prevented from reaching production via static checks and code review gates.

AI text-to-SQL guardrails

When the AI assistant generates SQL on behalf of an investigator, the generated SQL is parsed and validated against the same table whitelist and tenant-context requirement as human-authored queries. AI-generated queries cannot reach data outside the requesting user's role or the tenant boundary.

Input validation and schema enforcement

Inbound payloads are validated against typed schemas at the controller boundary; deserialization rejects unknown fields and unexpected types. Persistence-layer constraints (CHECK, NOT NULL, foreign key) enforce data invariants the application layer claims to uphold.

Periodic security audit and remediation

Internal security audits review the data path on a scheduled cadence with documented findings, remediation tickets, and re-test evidence. Audit summaries feed the SOC 2 Type II observation window with AtomAudits and align with HIPAA Security Rule risk-management requirements.

Responsible disclosure

Report a vulnerability.

If you believe you have discovered a security vulnerability in AEGIS ISD, please report it to our security team. We appreciate coordinated disclosure and will acknowledge verified reports promptly. We request that you do not test against production data, do not access accounts that are not your own, and do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate.

Security contact

  • Email: security@aegisisd.com
  • Use "Vulnerability Report" as the subject
  • Include reproduction steps and any relevant logs

Need our attestation reports?

Request the trust package.

Our SOC 2 Type II report (once issued), HIPAA Business Associate Agreement template, penetration-test executive summary, security questionnaire responses, and subprocessor detail are available to qualified customers and prospects under a mutual non-disclosure agreement.

How to request

  • Email legal@aegisisd.com
  • Include your organization and intended use
  • We will return a mutual NDA within two business days