Security architecture and engineering for healthcare and revenue cycle products, built for buyers who assess many vendors, recognize the standard answers and verify rather than accept.
Healthcare security review has changed. The people conducting it evaluate dozens of vendors a year, they have seen every policy document, and they ask the questions that distinguish an implemented control from a described one. Can one customer data reach another, and how is that enforced. What is in your non-production environments. Who at your company can query across customers. Those questions have architectural answers, and a policy response is recognized immediately.
The security review should confirm the architecture, not discover it. A certification tells a buyer you have a process, not whether the control exists, and increasingly they check.
In healthcare, a security assessment sits between a verbal yes and a signed contract, it can add months, and it is frequently handled by engineers pulled off the roadmap to answer a questionnaire under time pressure. That timing makes security a revenue capability rather than a compliance function, and it is rarely resourced as one. The answers assembled during the deal also reveal how much was built versus documented.
Underneath the commercial issue sits an architectural one. Most healthcare products enforce their most important control, keeping one customer data away from another, in application code rather than in structure, and that distinction is precisely what a serious reviewer is testing.
The Strongest Control Is the Weakest Implementation
Tenant separation enforced by conditions in queries means one omission is a cross-customer disclosure.
Non-Production Is Where the Exposure Sits
Real customer data copied into development, test and analytics environments with weaker controls and monitoring.
Certification Is Mistaken for Security
An audit confirms a process operated. It does not prove a specific architectural control exists.
Access Accumulates
Engineers, support staff, contractors and former team members retain standing access after the reason ended.
Your Incident Becomes Your Customer Incident
Customers carry notification obligations and need precise scope quickly.
Logs Become a Second PHI Store
Application, integration and AI logs retain payloads nobody intended to keep.
Find out what is in your non-production environments.
Not what the policy says. What is actually there: production copies, debugging extracts, demo datasets and migration snapshots. It is one of the most common serious findings and one of the cheapest to correct once located.
Two principles govern everything here. A control that depends on somebody writing code correctly every time is a convention rather than a control. And a control you cannot demonstrate to a customer is, from their perspective, a claim.
Step 1
Establish where protected information actually lives, including warehouses, backups, logs, non-production and support tooling.
Step 2
Assess how each control is enforced, distinguishing structural enforcement from application logic that has to be correct every time.
Step 3
Make tenant isolation structural, since it is the control buyers test hardest and the one most often implemented as a query condition.
Step 4
Reduce the protected information footprint, because the cheapest data to protect is the data you did not copy.
Step 5
Build access control around what people actually do, with support access scoped, justified, time-bound and logged.
Step 6
Move security into the pipeline, so scanning, dependency management and configuration checks run on every change.
Step 7
Design the audit trail for the questions that will be asked, including who accessed which customer data and when.
Step 8
Prepare the incident capability before an incident, including what customer notification obligations require from you.
Step 9
Produce evidence from the control rather than for the request.
The cheapest protected data to secure is the data you never copied.
Every environment, extract, log, backup and analytics store holding patient information is another place to control, monitor, retain, delete and explain. Footprint reduction is frequently the single largest risk reduction available, and it makes the estate simpler.
Three layers. The architecture determines what is possible, the engineering determines whether it holds under change, and the evidence determines whether a customer believes either.
Architecture
Tenant Isolation Design
structural separation through data access, analytics, caching, background processing, exports and AI paths.
Identity and Access Architecture
authentication, authorization, entitlement and scope as distinct concerns.
Data Protection Design
encryption, key management, minimization and residency.
Protected Information Footprint Reduction
locate patient data and remove it from places it should not be.
Engineering
Application Security
secure design across APIs, exports, reporting, background processing and tenant boundaries.
DevSecOps Pipeline
dependency, static, dynamic, secret and infrastructure checks on every change.
Secrets and Credential Management
managed storage, rotation, scoping and tested revocation.
Cloud and Infrastructure Security
configuration, network design and workload isolation.
Evidence
Audit and Access Logging
who accessed which customer data, when and why.
Security Monitoring
anomaly detection for access patterns, bulk retrieval and cross-tenant attempts.
Incident Readiness
detection, containment, investigation and customer notification.
Customer Evidence Package
current architecture, data flows, access model and control evidence.
What CaliberFocus does, and does not do.
Security engineering should remove exceptions rather than create more of them. We build reusable controls into architecture rather than documenting them into policy. We will also tell you when a certification you hold does not answer the question a buyer is actually asking. We are engineers rather than auditors, and the two produce different work.
These are the surfaces healthcare buyers examine. The third column is what a serious reviewer is actually trying to establish.
| Surface | What It Exposes | What a Reviewer Is Establishing |
|---|---|---|
| Application and User Access | What a logged-in user can reach | Whether entitlement is enforced per record or assumed from a role. |
| Reporting and Analytics | Aggregated data across records | Whether reporting inherits user scope or runs with broader access. |
| APIs and Integrations | Programmatic access at machine speed | Whether credential scope is real and whether revocation works. |
| Exports and Downloads | Data leaving the platform permanently | What an export can contain, who can generate one and whether it is logged. |
| Support and Engineering Access | Staff reaching customer data to help | Whether it is scoped, justified, time-bound and reviewed, or standing. |
| Non-Production Environments | Copies of production data | Whether real patient data is there, which is the most common finding. |
| AI and Model Paths | Prompts, retrieval, context and training data | Whether tenant boundary holds through vector stores and shared context. |
| Partner and Third-Party Access | Another company reaching your platform | What they can reach and how you assessed them. |
The Question Behind Most Healthcare Security Questionnaires
Can one customer data reach another, and how do you know? Encryption, certification, network design and policy all matter, and none of them answers it. Reviewers quickly distinguish structural separation from application logic that must be correct every time.
Access-control failures rarely come from a missing check. They come from collapsing four separate questions into one permission decision made at login.
| Question | What It Determines | What Goes Wrong When It Is Merged |
|---|---|---|
| Who Is This | Identity of the person or system | Authentication is treated as authorization, and knowing who becomes permission to act. |
| What May They Do | Capability and action | A read credential performs writes because nobody separated the two. |
| Whose Data May They Reach | Tenant and customer scope | The single most consequential failure in a multi-tenant healthcare product. |
| Which Part of It | Record, population and field scope | A user with legitimate access to a customer reaches every record in it. |
Engineering Discipline
Enforce tenant scope where it cannot be omitted. Carry the boundary through application, analytics, cache, queue, background jobs, exports, logs, support tooling and AI context. Inherit scope from the user rather than the builder. Make revocation an action, not a ticket. Test the boundary adversarially. Every API request should establish identity, tenant, permission, resource and action. Minimize before you protect.
When something happens in your product, customers carry obligations that depend on information only you have: what was accessed, whose data, over what period and by whom. What you can produce was determined by logging decisions made long before the incident.
Detection
Bulk retrieval, cross-tenant attempts, unusual access timing and credential behaviour that looks like a highly productive integration.
Logging
Who accessed which customer records and when, retrievable per record and per customer.
Containment
Suspend a credential, partner or capability without taking the product down for everyone.
Investigation
Retain enough detail to establish scope quickly.
Customer Notification
Agree what you will provide, how quickly and in what form before the incident.
Pipeline Security
Dependency, static, dynamic, secret and configuration scanning on every change.
A scanner produces findings. A programme produces closure.
Discover, validate, prioritize, assign, remediate, verify and close. Prioritize using exposure, data sensitivity, exploitability, privilege and tenant impact—not severity score alone. Detection without a response path is documentation.
An audit confirms that a process operated over a period. A buyer asking how tenant isolation is enforced, what is in non-production or who can query across customers is asking something an attestation does not cover. Both matter.
HIPAA Engineering
Engineer minimum necessary, audit and breach-notification capability into the product. Maintain the protected-information inventory, supplier position, retention and deletion.
Access Governance
Review staff, contractors, partners and service accounts. Make support access scoped, justified, time-bound and logged. Test joiner, mover and leaver processes.
Auditability
Reconstruct access per record and customer, log administrative changes, align retention to obligations and produce evidence on request.
Operational control
Distinguish identified, accepted, mitigated, transferred and pending risks. Keep the customer evidence package current and track testing findings to closure.
Produce the list of everyone who can reach customer data across tenants.
People and systems, today, through any route: application, warehouse, BI tool, support console, production credential, notebook or integration. Then note which are logged and reviewed. Producing it yourself is considerably better than being asked for it.
Security work is usually reported as findings closed and certifications held. Neither indicates whether the controls a buyer tests actually exist or whether the review is still adding months to the sales cycle.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Questions Needing Investigation | Enterprise security questions requiring an engineer to investigate before you can answer | A mature product already knows where PHI is, who can reach it and how isolation is enforced. |
| Review Cycle Time | Elapsed time from assessment starting to clearance, and engineering hours consumed | A revenue measure disguised as a compliance one. |
| Remediation Demanded | Conditions and remediation required before a deal proceeds | What the gap between claimed and implemented is costing. |
| Structural Enforcement | Controls enforced in architecture versus application logic | The honest measure, and the one a reviewer is testing. |
| Protected Data Footprint | Environments and stores holding patient data, and reduction achieved | The largest available risk reduction and simplest to explain. |
| Cross-Tenant Access Breadth | People and systems able to reach data across customers, and whether logged | The answer buyers want and usually longer than documentation suggests. |
Honest expectation setting
An assessment may conclude authentication is strong while authorization is inconsistent, tenant isolation needs work outside the transactional application, production access is broader than necessary, logs retain more protected information than intended, scanning exists while closure does not, or AI capabilities have more data and tool access than required. Expect at least one documented control to be enforced by application logic rather than structurally, and expect part of the recommendation to touch the roadmap.
We will assess how your controls are actually enforced rather than how they are described, test the tenant boundary through every path, map where protected data exists including the places nobody decided on, audit who can query across customers, and review what you could produce in an incident. The non-production and access findings usually arrive in the first week.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
