Public assurance center · Updated July 2026

Trust starts with clear boundaries.

Cloud Health Office is source-available payer infrastructure, not a black-box certification claim. This page distinguishes controls visible in the repository, reference deployment patterns, customer responsibilities, cloud-provider assurance, and the work required before production PHI processing.

Inspect the architecture → Report a vulnerability privately

Source visible Security-sensitive implementation and infrastructure patterns can be inspected in the public repository.

Synthetic by default Public tests, demonstrations, screenshots, and benchmark artifacts must not contain real PHI or production credentials.

Your-cloud option Customer-controlled deployment boundaries keep infrastructure, identity, keys, and data ownership explicit.

No borrowed badges Azure certifications apply to Microsoft's audited environment; they are not presented as Aurelianware certifications.

Public & implemented

Secure development checks

Automated dependency, secret, container, and PHI-focused checks run in the public repository. Findings still require review and remediation.

Reference architecture

Deployment security patterns

Infrastructure supports private endpoints, managed identities, RBAC, key-management options, audit logging, and tenant-aware routing.

Validation required

Production effectiveness

Identity, networks, keys, logging, retention, integrations, recovery, and operating procedures must be verified in the target environment.

Not currently claimed

Aurelianware certifications

This site does not claim that Aurelianware or Cloud Health Office currently holds SOC 2 Type II or HITRUST certification.

Contractual

BAA, SLA, and support

PHI processing, support coverage, incident-notification targets, availability commitments, and retention terms are defined per engagement.

No public production claim

Capacity and compliance

Published benchmarks are local validation evidence. Production capacity and regulatory posture require customer-specific testing and review.

Control domain	Cloud Health Office provides	Customer validates and operates	Cloud provider provides
Identity and access	Authentication, authorization, RBAC, tenant-context, and managed-identity integration patterns.	Identity-provider configuration, role assignments, access reviews, MFA policy, and workforce lifecycle.	Identity and key-management service availability and underlying platform controls.
Data protection	Encryption configuration, PHI-aware logging, data partitioning, retention options, and secret-store integration.	Approved data classes, key ownership, retention schedule, backup policy, export controls, and deletion acceptance.	Encryption primitives, regional storage services, physical media controls, and documented service assurance.
Network security	Private-endpoint, ingress, egress, service-to-service, and network-policy reference patterns.	Production topology, DNS, firewall, allow-list, egress, certificate, and administrative-access configuration.	Virtual-network and managed-service isolation capabilities plus infrastructure availability.
Monitoring and response	Structured audit events, telemetry redaction patterns, health signals, and alerting templates.	Alert routing, on-call coverage, SIEM integration, incident command, evidence retention, and notification decisions.	Platform logs, regional status, native monitoring services, and provider incident communications.
Compliance and contracts	Control documentation, implementation evidence, architecture review, and contract-specific commitments.	Risk analysis, policies, vendor review, BAA determination, regulatory interpretation, and production acceptance.	Service-specific compliance documentation and contractual terms for eligible cloud services.

Reference defense-in-depth layers for network isolation, telemetry redaction, encryption keys, data lifecycle controls, and automated delivery checks. — Reference safeguard layers. Availability and effectiveness depend on the selected cloud services, configuration, customer operating model, and production validation.

Before PHI processing

Define the parties' HIPAA roles and execute a BAA where required.
Approve every service, region, data flow, support path, and subprocessor in scope.
Complete security architecture, threat-model, retention, recovery, and access reviews.

Inside the deployment

Keep credentials in approved secret stores and use least-privilege identities.
Redact or omit PHI from logs, traces, screenshots, benchmark artifacts, and support messages.
Apply tenant, authorization, network, encryption, audit, and lifecycle controls to the accepted design.

Public and support channels

Never submit PHI, production credentials, tenant identifiers, or sensitive logs through public GitHub channels.
Use private security reporting for suspected vulnerabilities.
Use only synthetic or contractually approved de-identified material for public evidence.

Cloud Health Office is not currently presented as a packaged production appliance. Deployment operators remain responsible for their hosting environment, controls, agreements, and regulatory posture.

Repository controls

Language-specific tests and security-oriented validation
Dependency and container scanning
Secret scanning and PHI-focused validation
Pull-request review before changes reach main

Security-sensitive defaults

Least-privilege local credentials
Secret-store and environment-variable patterns
Authorization, tenant-isolation, and data-handling tests
Deterministic synthetic fixtures for regression and scale evidence

Review the evidence

Reference infrastructure topology showing ingress, application services, messaging, storage, identity, monitoring, and administrative boundaries. — Reference infrastructure topology for architecture review. Exact services, trust boundaries, and controls must be reconciled with the target payer environment.

Email the security contact

security@cloudhealthoffice.com is the private reporting channel.

Provide reproducible detail

Include the affected component, steps, potential impact, and redacted evidence. Do not include real PHI or production credentials.

Protect affected parties

Coordinate disclosure privately while the issue is evaluated and remediated. Public reporting can follow an agreed disclosure path.

Define scope and data

Identify workflows, users, integrations, data classifications, regions, recovery objectives, operating model, and regulatory responsibilities.

Validate the deployment

Test identity, authorization, isolation, encryption, redaction, auditability, recovery, capacity, failure handling, and operational procedures.

Accept and operate

Execute required agreements, record exceptions, approve evidence, establish support and incident paths, and monitor the accepted control baseline.

Reference tenant-aware request routing through a shared gateway into tenant-specific configuration, data, messaging, and audit lanes. — Tenant-aware routing is an implementation pattern, not proof of complete isolation by itself. Authorization, storage partitioning, messaging, configuration, audit, and deployment topology must be tested together.

Bring your security questionnaire and your architecture team.

We will review the source-visible controls, identify deployment-specific gaps, and define the evidence required before your organization accepts a pilot or production workload.

Schedule a security review → Send requirements first