Compliance engineering for regulated software
Security reviews and audits stall products when the evidence has to be rebuilt at the end. Agnotic Technologies builds the controls into the software and collects the evidence as it ships.
15-Minute Scoping CallHIPAA 164.312(b) Audit controls
- Control
- Append-only audit log for PHI reads and changes
- Test
- Automated check on every release
- Evidence
- Log export, test report, access review
- Owner
- Engineering lead, reviewed by compliance
Trusted by global innovators
What is healthcare compliance software development?
Healthcare compliance software development is building software so that the safeguards a regulation or audit framework expects are part of the product itself. Agnotic Technologies designs access control, audit logging, encryption and data flows to meet HIPAA, SOC 2, GDPR or FDA expectations, and produces the evidence your auditors and customers ask for.
Which compliance framework applies to your product?
Start from your situation. Many products fall under more than one row.
| If your product | Framework | What it means for the build |
|---|---|---|
| Stores or sends PHI for a provider, payer or their vendor | HIPAA | Security Rule safeguards, audit logging and a BAA with every PHI vendor |
| Is sold to enterprises that ask for a security report | SOC 2 | Documented controls and evidence a CPA firm can examine |
| Serves health systems that require a healthcare-specific framework | HITRUST | Controls mapped to the HITRUST framework and assessed by an authorized assessor |
| Processes health data of people in the EU or UK | GDPR | A lawful basis for health data, consent where needed, data minimization and retention rules |
| Diagnoses, treats or drives clinical decisions | FDA SaMD | A regulatory assessment first, then a documented software lifecycle if it is a device |
| Handles PHI across many systems and vendors | PHI data security | Encryption, key management, de-identification and a data-flow map |
| Collects health data from consumers directly, outside a HIPAA relationship | FTC Health Breach Notification Rule (16 CFR Part 318) | Breach detection and a consumer notice process. Evidence: a map of every SDK and analytics tag that receives health data |
| Stores records from a federally assisted substance use disorder program | 42 CFR Part 2 | Part 2 records labeled and kept apart, with consent checked before each disclosure. Evidence: consent records and a disclosure log |
| Is certified health IT, or exchanges electronic health information as a provider or network | Information blocking (45 CFR Part 171) | Access for patients and partners through standard APIs without extra hurdles. Evidence: the exception relied on for any request you decline |
| Shows predictive scores or decision support inside certified health IT | ONC decision support interventions (45 CFR 170.315(b)(11)) | Source attributes, such as the developer and funding source, that users can review. Evidence: the attribute record for each intervention |
| Texts or calls patients with an autodialer or prerecorded voice | TCPA rules (47 CFR 64.1200) | Consent stored per phone number and opt-outs honored in every channel. Evidence: a timestamped consent log |
| Collects consumer health data from people in Washington State | My Health My Data Act (RCW 19.373) | Consent before collection and a consumer health data privacy policy linked from the homepage. Evidence: consent records and the published policy |
| Runs a health program online for a recipient of federal financial assistance | Section 1557 accessibility (45 CFR 92.204) | Web content and apps that people with disabilities can use, built and tested to WCAG 2.2 AA. Evidence: accessibility test reports |
Which compliance frameworks do we build for?
Each framework page covers the requirements, the engineering work and the evidence for that framework.
- HIPAAHIPAA compliant software developmentSecurity Rule safeguards built into the architecture.
- SOC 2SOC 2 software developmentControls and evidence ready for a SOC 2 examination.
- HITRUSTHITRUST software developmentControls mapped to the HITRUST framework.
- GDPRGDPR compliant softwareConsent, minimization and retention for health data.
- FDAFDA SaMD software developmentLifecycle and documentation for software as a medical device.
- PHIPHI data securityEncryption, key management and de-identification.
- AdvisoryHIPAA consultingGap assessments, risk analysis and remediation roadmaps.
Which global standards does our compliance work cover?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
What do we own and what does your team own?
Compliance is shared. This is the usual split on a build engagement.
Risk analysis
- Agnotic builds or provides
- Technical input: data flows, threats and controls for the software
- Your team owns
- The organization's risk analysis and sign-off
Access and audit controls
- Agnotic builds or provides
- Role-based access, MFA, audit logging and alerts in the product
- Your team owns
- Who gets access, and reviewing the access logs
Encryption and hosting
- Agnotic builds or provides
- Encryption at rest and in transit, secure infrastructure as code
- Your team owns
- The cloud account, and the BAA with the cloud provider
Policies and training
- Agnotic builds or provides
- Engineering procedures for the code we write
- Your team owns
- Company policies, workforce training and HR controls
Evidence
- Agnotic builds or provides
- Test results, configuration exports and change history from delivery
- Your team owns
- Collecting evidence across the company for the auditor
Audit or assessment
- Agnotic builds or provides
- Answers on the software and its controls
- Your team owns
- Choosing and working with the auditor or assessor
What does a requirement to evidence map look like?
A sample of the map we keep during a build. Each requirement points to a control and to the evidence that proves it works.
HIPAA 164.312(a)(2)(i) Unique user identification
- Control in the software
- Per-user accounts through the identity provider, no shared logins
- Evidence
- Identity provider configuration, account review
HIPAA 164.312(b) Audit controls
- Control in the software
- Append-only audit events for every PHI read and change
- Evidence
- Log samples, alert rules, automated test results
HIPAA 164.308(a)(7)(ii)(A) Data backup plan
- Control in the software
- Automated backups with restore tests
- Evidence
- Backup schedule, restore test record
GDPR Article 9 health data
- Control in the software
- Consent capture and purpose limits for health data
- Evidence
- Consent records, data map, retention settings
SOC 2 security criteria: logical access
- Control in the software
- Least-privilege roles and quarterly access reviews
- Evidence
- Role matrix, access review sign-off
How does compliance fit into delivery?
Map data and risks
We map where sensitive data is created, stored and sent, and which rules apply to each flow.
Design the controls
Access, logging, encryption and retention are designed into the architecture before features are built.
Collect evidence as we build
Tests, configuration and change history are captured in each release instead of rebuilt before an audit.
Support the review
We answer the technical questions from your auditor, assessor or customer security team.
Where can you see this approach in practice?
What do the regulators and standards bodies say?
The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)A SOC 2 report is an assurance report, issued by a CPA, on a service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy.
Source: AICPA & CIMAThe GDPR treats data concerning health as a special category of personal data, which may be processed only under one of the conditions listed in Article 9.
Source: Regulation (EU) 2016/679, Article 9 (EUR-Lex)FDA's guidance on device software functions focuses oversight on software that meets the definition of a medical device and could put patient safety at risk if it does not work as intended.
Source: FDA, Policy for Device Software Functions and Mobile Medical Applications (2022)