What HIPAA integrity controls for transmitted ePHI require
If you must show that electronic protected health information (ePHI) moving across a network is not altered without detection, the requirement you are answering is transit integrity under 164.312(e)(2)(i). The specification asks for security measures that ensure electronically transmitted ePHI is not improperly modified without detection until it is disposed of. It sits under the transmission security standard in 164.312(e)(1), next to the encryption specification in 164.312(e)(2)(ii). In plain terms, the question an assessor will ask is whether you could tell if a message, file or API payload was changed between sender and receiver, and what you did about it. Do not confuse this with the integrity standard at 164.312(c)(1), which covers protection of ePHI from improper alteration or destruction while it is stored. The mechanism to authenticate stored ePHI in 164.312(c)(2) is a separate addressable specification. Transit integrity is about the path: TLS sessions with authenticated record integrity, signed message formats, message authentication codes on API traffic, and checksums or hash verification on file transfers between systems. Your documentation should name which of these applies to each ePHI data flow, because one flow may rely on TLS while another moves files over a protocol with no built-in integrity check. This specification is addressable under 164.306(d)(3). You must assess whether it is reasonable and appropriate for each system. If you decide it is not, you must document why and implement an equivalent alternative measure if one is reasonable and appropriate. Many teams skip the assessment and assume transport protection is covered, which is the main reason this control is hard to prove. Confirm with your risk analysis whether every ePHI transfer path has a documented integrity decision, and check whether the proposed Security Rule revision (90 FR 898) would change how addressable specifications are treated before you finalize your position.
Which ePHI transmissions and systems fall in scope for integrity in transit
Integrity in transit applies wherever ePHI moves over a network, which covers far more than the public website. The risk analysis should decide which of these paths receive a documented integrity mechanism, and each decision should be recorded so an assessor can trace it.
Patient portals and APIs
Patient portals, mobile apps and partner APIs carry ePHI directly to and from individuals and third parties. Confirm that every endpoint negotiates a protected channel, that request and response bodies cannot be altered without detection, and that API gateways do not terminate protection in a place where content is changed before reaching the application. Record which endpoints the risk analysis placed in scope and why. Patient-facing paths are often the first place an assessor looks.
Internal service-to-service calls
Microservices, message queues and internal batch jobs often move ePHI across networks that teams assume are trusted. Inventory these flows from application code and service meshes, not from the network diagram alone. Each flow that carries ePHI needs a documented mechanism, such as mutually authenticated channels with message integrity, or a documented reason it is not reasonable and appropriate, with an equivalent alternative measure recorded.
Database replication and HL7 or FHIR interfaces
Database replication streams, HL7 v2 feeds to laboratory and imaging systems, and FHIR exchanges with other providers move large volumes of clinical data, often between systems owned by different teams. Check whether replication links are encrypted and authenticated, whether interface engines validate message integrity, and whether any intermediate queue or file share can change a message in transit. These interfaces are frequently missing from older risk analyses.
Email, file transfers and backup transfers
Email attachments, SFTP drops, managed file transfer and replication of backups to a third-party or cloud location all move ePHI beyond the organization's direct control. Ask which transfers rely on the recipient's server policy, which use protected channels end to end, and whether backup providers can confirm that copies arrive unaltered. Business associates that receive these transfers must be covered by a written agreement that addresses the same duties.
Remote access and vendor support paths
VPNs, remote desktop sessions, jump hosts and vendor support tunnels can expose ePHI to transfer, screen capture or session tampering, and they are often outside the normal monitoring scope. Include them in the inventory, confirm which ones carry ePHI during support sessions, and check that the protection used applies to the session content and not only to the login. Vendor-managed paths should be assessed alongside the vendor's own obligations.
Business associate and subcontractor paths
Business associates and their subcontractors carry the same Security Rule duty for the ePHI they transmit on behalf of a covered entity, so a path operated by a vendor is still in scope. Map each vendor path into the risk analysis, obtain the vendor's description of its integrity mechanism, and confirm that the business associate agreement reflects the obligations that apply to that path. Vendor evidence should be reviewed on the same schedule as internal evidence.
How an assessor tests integrity controls for ePHI in transit
This table walks through the steps an assessor takes to test 164.312(e)(2)(i), from confirming the risk analysis covers each transmission path to sampling configuration and logs. Read each row as a test step, the evidence it calls for, and the findings that most often stop an organization from showing the control works.
| Test step | Evidence requested | Common findings |
|---|---|---|
| Confirm the risk analysis covers transmission paths | Current risk analysis and data flow maps listing every network path that carries ePHI, including EHR interfaces, APIs, email, file transfers and remote access | Risk analysis covers stored ePHI only, or lists systems but omits interfaces, vendor connections and backup transfers |
| Check each path for an integrity mechanism | Inventory of transmission paths with the mechanism applied to each, such as TLS with message authentication, signed payloads or checksums | Paths with no named mechanism, or a general statement that traffic is secure without per-path detail |
| Review documented decisions for addressable use | Written assessment under 164.306(d)(3) for any path without an integrity mechanism, with the reason and the equivalent alternative measure | Decisions undocumented, dated before the current architecture, or citing a reason that no longer holds |
| Review configuration of transport protections | Exported configuration for TLS endpoints, VPN gateways, API gateways and mail relays showing protocol versions, cipher settings and integrity-related options | Legacy protocol versions still enabled, mismatched settings between client and server, or configuration drift from the documented baseline |
| Sample logs for integrity failures | Log samples showing rejected or failed integrity checks, TLS handshake errors and alerts, with the review record for those events | Logs not retained for the assessed period, no alerting on failed checks, or no evidence anyone reviewed the events |
| Test that tampering is detected | Results from a controlled test, such as a modified message or altered payload sent across the path, with the detection outcome recorded | Integrity claims in policy with no test behind them, or tests run once and never repeated after changes |
| Trace integrity to change management | Change records for gateways, certificates and interface updates that affect transmission paths, with approval and re-test evidence | Certificate or cipher changes made outside change control, so the documented configuration no longer matches production |
| Confirm third-party transit is covered | Business associate agreements and vendor evidence describing how ePHI integrity is protected on vendor-managed links | Vendor links treated as out of scope, or reliance on a vendor statement with no supporting configuration or test record |
How to implement transit integrity controls step by step
This sequence turns the addressable transit integrity specification in 164.312(e)(2)(i) into a documented decision, a configured mechanism and evidence that the mechanism works, so an assessor can trace each ePHI path from the risk analysis to a tested control.
Inventory ePHI transmission paths from the risk analysis
Start with the risk analysis and list every route by which ePHI leaves a system or crosses a network boundary. Include web applications, APIs, interfaces to labs and payers, email, file transfers, replication between sites and backup traffic to cloud or offsite storage. The privacy or security lead and the system owners should confirm the list together. The output is an approved path register that names each path, its endpoints, the data it carries and the owner responsible for it.
Assess whether an integrity mechanism is reasonable
For each path in the register, decide whether an integrity mechanism is reasonable and appropriate. Consider the sensitivity of the data, the likelihood of tampering on that route, the threats identified in the risk analysis, the cost of the mechanism and the systems it must work with. Record the reasoning next to each path. The output is a per-path determination that is either implement or document an alternative, reviewed and dated by the security official.
Select and configure integrity mechanisms
Where the determination is to implement, choose a mechanism that can detect modification of ePHI in transit, such as the protections provided by the transport layer, message authentication in the application or interface engine, or signed payloads. Configure it on both ends of the path and disable weak or legacy options. Store the settings as configuration baselines under version control, so each change is reviewed. The output is a baseline file or record for each path, with the owner and approval date.
Document equivalent alternatives and the reasoning
Where a mechanism is judged not reasonable and appropriate, or where an equivalent measure is used instead, write down why the standard measure was not adopted and what replaces it. The alternative must still detect improper modification of ePHI in transit. Have the decision approved and signed by the accountable officer and retained with the risk management records. The output is a signed decision record for each deviation, linked to the path register.
Validate integrity controls with tests
Test each configured path by sending traffic that has been altered in transit and confirming the receiving system rejects it, logs the failure or raises an alert. Include certificate and handshake checks, replay or tampering tests on interfaces, and checks that downgraded or unauthenticated connections fail. Use a test environment that mirrors production where possible. The output is a dated test report that lists each path, the method, the result and the defects raised.
Set monitoring, logging and periodic review
Forward integrity failures, certificate errors and configuration changes on each path to the logging platform that supports audit controls and information system activity review. Assign an owner for alerts and define how they are triaged. Review the path register, baselines and decision records on a set schedule and after any system change, network change or incident. The output is a monitoring configuration, an alert runbook and a review log showing who reviewed what and when.
Which self-hosted open-source tools support transit integrity evidence
Application-layer traffic carrying ePHI, such as web forms, patient portals and APIs, is where many modification attempts arrive. Coraza is an Apache-2.0 licensed web application firewall that is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP requests and responses for attack patterns such as SQL injection, cross-site scripting and code injection, and it has integrations for Caddy, HAProxy, Traefik and Nginx.
- Attack payload detection: Coraza can block requests that carry injection payloads before they reach the application, and its logs record the rule matches.
- Ruleset compatibility: Existing ModSecurity SecLang rules and the OWASP Core Rule Set can be reused, which helps teams carry over tuned configurations.
- Proxy integrations: Connectors exist for Caddy, HAProxy, Traefik and Nginx, so the WAF can sit in front of the reverse proxy already in use.
- Rule tuning records: Changes to rulesets and exclusions should be version-controlled so assessors can see what was in force at a given date.
- Clear limits: A WAF detects and blocks attack payloads. It does not by itself prove that transmitted ePHI is unmodified, so it supports the evidence rather than replacing it.
Confirm in your own environment which rulesets, proxy integration and logging destination you run, and how long those logs are retained.
Network controls decide which hosts can reach systems that carry ePHI and which traffic paths exist at all. OPNsense is a BSD-2-Clause licensed firewall platform built on a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so rules stay readable as the environment grows.
- Explicit path rules: Rules restrict which sources can reach ePHI segments, so unexpected paths are blocked and documented.
- Aliases for address groups: Aliases let teams maintain host and network groups in one place and reference them across rules.
- Per-rule logging: Each rule can log its matches, and those entries can be reviewed in the live log view.
- Change history: Rule changes should be tracked with the reason and approver, since the configuration is part of the evidence.
- Limits of network filtering: Packet filtering controls paths and ports. It does not inspect payload content or verify that data arriving over an allowed path is unchanged.
Confirm which logging options, log retention and export methods your OPNsense version provides, and whether logs reach your central review process.
Encrypted transport protects ePHI from modification in transit only when both endpoints can prove who they are and when certificates are managed reliably. FreeIPA is a GPL-3.0-or-later licensed identity platform that includes an integrated certificate authority based on Dogtag for issuing and managing certificates. OpenBao is an MPL-2.0 licensed fork of Vault, and its PKI secrets engine issues dynamic X.509 certificates, so services receive certificates without generating keys and certificate signing requests by hand.
- Internal CA with issuance records: FreeIPA's Dogtag-based CA issues and tracks certificates, giving a record of which endpoints hold valid certificates.
- Dynamic certificates: The OpenBao PKI secrets engine issues short-lived X.509 certificates on request, which reduces manual handling of private keys.
- Revocation and renewal: Confirm how each tool handles revocation, renewal and expiry monitoring in your deployment.
- Endpoint identity: Certificates tie a TLS session to a named service, which supports the authentication side of the transport evidence.
- Limits of certificates: A valid certificate authenticates an endpoint. It does not show that the data sent over the session was unchanged after encryption ended at an intermediary.
Confirm the certificate lifetimes, key storage and audit logging for each CA in your environment, and document which services rely on which issuer.
Evidence that shows transmitted ePHI is protected from undetected change
An assessor testing 164.312(e)(2)(i) starts by asking where ePHI travels and then looks for proof that changes in transit would be noticed. The artifacts below connect each transmission path to a documented decision, a working control and a record that shows the control kept operating between reviews.
Transmission path register
A current inventory of every network path that carries ePHI, including interfaces between EHR, lab, billing, imaging and cloud services, the protocol on each path and the owner who approves changes. Link each entry to the risk analysis entry that rated it. Confirm the register lists paths your staff use, not only the ones in the original design documents. Review it whenever an interface is added, retired or moved to a new network segment.
Addressable decision records
For each addressable mechanism on a path, a dated record stating whether it is reasonable and appropriate, what was implemented, and where it was not, why it was declined and which equivalent alternative replaced it. Assessors look for the reasoning, not only the outcome. Keep the record tied to a named risk owner and revisit it when the path's threat profile or data volume changes.
Configuration baselines and change records
Approved configuration baselines for firewalls, reverse proxies and web application firewalls that front ePHI traffic, with change tickets showing who altered a rule, why and when it was reviewed. A rule that permits unexpected traffic or disables inspection is a finding waiting to happen. Compare running configuration against the baseline on a fixed schedule and record the result, even when nothing has changed.
Tamper detection test results
Documented tests that send deliberately malformed or altered requests through the protected path and show whether the platform blocked or logged them. Example (illustrative): a test that modifies a message body in a staging interface and confirms the receiving service rejects it or raises an alert. Record the test scope, the expected result, the actual result and the remediation for any gap. Repeat tests after each change to the path.
Firewall and WAF log samples
Retained log extracts from the packet filter and web application firewall showing matched rules, blocked sessions and inspection alerts for ePHI interfaces. Keep samples that show both normal and rejected traffic so the reviewer can see the control working. Pair the samples with review records that show a person examined them, what they found and what follow-up occurred. Confirm your log retention meets your own policy and the documentation requirements in your organization.
Certificate issuance and renewal records
An inventory of TLS certificates and their issuing authority, with records of issuance, renewal, revocation and the key length and protocol in use on each ePHI endpoint. Expired or self-signed certificates on clinical interfaces undermine the integrity claim because peers cannot verify who they are talking to. Automated issuance produces its own audit trail, so keep the issuance log alongside the inventory and reconcile the two during each review.
What meeting transit integrity controls costs in money and effort
This table breaks down the cost components of meeting 164.312(e)(2)(i) for ePHI in transit, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to know what to request in a quote. No dollar figures or durations are given because none were supplied for this topic.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling licenses or subscriptions | Vendor of any commercial gateway, VPN, monitoring or certificate product | Usually recurring | Number of endpoints, throughput and support tier; open-source alternatives such as Coraza or OPNsense can remove license spend but not operating effort |
| Path inventory and data flow mapping | Internal engineers or an implementation partner | One-time, then periodic refresh | Number of interfaces, EHR and lab connections, business associate links and undocumented feeds |
| Configuration of TLS, gateways and integrity mechanisms | Internal platform team or implementation partner | One-time per path, plus change work | Age of legacy systems that cannot support current protocols and the number of distinct transport types |
| Certificate lifecycle management | Internal PKI owner or platform team | Recurring | Number of services needing certificates and how often keys rotate; automated issuance such as FreeIPA or OpenBao PKI reduces manual steps |
| Evidence collection and upkeep | Compliance lead, security engineers and system owners | Recurring | How often paths change, whether logs and configuration exports are automated, and how many systems share one evidence set |
| External testing or review of transit controls | Independent testing firm or assessor | Recurring, per engagement | Scope of interfaces tested, whether tests cover tampering and downgrade attempts, and retest cycles after fixes |
| Auditor sampling and testing | Independent auditor or assessor | Per assessment cycle | Number of paths sampled, quality of documentation and how many exceptions need explanation or alternative measures |
Who owns transit integrity controls, the partner and the auditor
The covered entity or business associate owns the Security Rule obligation. For transmission integrity, that means deciding whether mechanisms to detect improper modification of ePHI in transit are reasonable and appropriate, documenting that decision, and accepting the residual risk. Under 45 CFR 164.306(d)(3), an addressable specification is not optional by default: the entity must assess it, implement it if reasonable and appropriate, or document why not and adopt an equivalent alternative if one is reasonable.
- Risk decisions: Record which transmission paths carry ePHI, which integrity mechanism protects each one, and why any alternative was chosen.
- Control ownership: Name an accountable owner for each mechanism, such as the platform team for TLS settings or the application team for message signing.
- Policy and procedure: Maintain written procedures for how integrity failures are detected, triaged and escalated.
- Review cycle: Confirm that the risk analysis is updated when systems, network paths or vendors change.
- Sign-off: Keep the risk decision approved by the security official, not delegated silently to an engineer.
Confirm with your counsel and security official which decisions must stay in-house before you sign any scope document.
An implementation partner prepares the systems that carry integrity controls and the evidence that shows how they work. DeployOpen, for example, plans, deploys and hardens self-hosted open-source platforms inside the client's own infrastructure, and runs security testing of application and transmission paths. The partner does not decide whether a risk is acceptable and does not issue a compliance opinion.
- Configuration work: Set up TLS versions, cipher policies, certificate issuance and rotation, and web application firewall rules for ePHI endpoints.
- Evidence preparation: Export configuration baselines, change records, log samples and test results that the organization can present to an assessor.
- Security testing: Test whether modification of traffic in transit is detected, for example by probing with altered requests against the configured controls.
- Documentation handover: Deliver runbooks and a clear statement of what each control does and does not cover.
- Fixed scope: Agree deliverables, responsibilities and timelines in writing before work starts, and confirm which items are the client's to operate afterward.
Ask the partner which evidence it will hand over and who holds the final records.
An independent auditor, assessor or certification body is the only party that tests the control and issues a conclusion about it. HHS states that no Security Rule standard requires certification and that HHS does not recognize private certifications, so the conclusion comes from the organization's own compliance program, its assessors and, where HHS acts, from OCR's investigation. Whatever assessment you commission must be independent of the people who built the controls.
- Testing: The assessor samples transmission paths, inspects configurations and reviews evidence for detected modifications.
- Limits of role: An auditor who has designed or operated the controls usually cannot also test them without a conflict.
- Report types: Any report issued must state its scope, period and limitations in its own words.
- Independence rules: Check the assessor's conflict-of-interest policy before engaging it.
- Reliance: Ask whether a report can support an OCR inquiry, and what it does not cover.
Confirm the assessor's independence and the exact scope of its report before relying on it.
Where organizations fall short on transit integrity and how to close it
The integrity specification in 164.312(e)(2)(i) is addressable, so most gaps come from decisions that were never written down or from transmission paths the risk analysis never saw. The cards below cover the failures assessors find most often and a practical fix for each.
No documented decision on the specification
Many teams treat the addressable specification as optional and never record a decision. Under 45 CFR 164.306(d)(3), the entity must assess whether integrity controls are reasonable and appropriate, implement them if so, and otherwise document why not and adopt an equivalent alternative. For each transmission path, record the assessment, the reasoning, the owner and the date. Check that the record matches what the systems actually do.
Encryption assumed to prove integrity
Teams often point to TLS as proof of integrity without checking what it covers. Transport encryption protects ePHI from disclosure and also detects tampering on the wire, but only when the endpoints validate the session properly. Check that certificate validation is enabled on every client, that legacy protocol fallbacks are disabled, and that the evidence shows the configuration in force, not only the vendor default.
Interfaces missing from the risk analysis
Vendor APIs, nightly file drops, SFTP folders, HL7 feeds and fax-to-email gateways often sit outside the inventory of systems that touch ePHI. Each one is a transmission path that needs an integrity decision. Walk the data flows with the integration owners, list every inbound and outbound interface, and confirm each appears in the risk analysis with its protection method.
Certificate renewal failures
An expired or misconfigured certificate can force teams to disable validation to restore service, which quietly removes the integrity check. Automate issuance and renewal where possible. OpenBao's PKI secrets engine can issue short-lived X.509 certificates to services without manual key and signing requests, and FreeIPA includes a Dogtag-based certificate authority for internal certificates. Confirm renewal alerts reach an owner before expiry.
Logs written but never reviewed
Gateways, firewalls and web application firewalls can record transmission events and rule matches, but a log nobody reads does not show that integrity is working. Define which events matter, such as blocked requests, certificate validation failures and rule matches, and assign a reviewer and cadence. OPNsense can log each rule match, and Coraza can run OWASP Core Rule Set rules that block injection attempts in transit. Keep evidence of each review.
Questions buyers ask about transit integrity before hiring help
How much effort does transit integrity take to implement?
The effort depends on how many network paths carry ePHI and how many of them already protect data in transit. Most of the work sits in inventorying where ePHI moves, choosing a mechanism for each path (for example, TLS with message authentication for web and API traffic, or an encrypted tunnel for site-to-site links), and documenting the decision. The specification is addressable, so the entity must first record whether integrity controls are reasonable and appropriate for each path. Ask any provider to break its estimate into inventory, configuration, testing and documentation, and to state which of those steps assume an existing risk analysis.
Can our own team meet this specification without outside help?
Yes, if the team has staff who can map ePHI flows, configure network and application controls, and write the decision records the rule expects. The Security Rule does not require a particular vendor or a consultant. Teams that lack network or application security experience often use outside help for the configuration and testing steps while keeping ownership of the risk decision. The HHS risk analysis tool and NIST SP 800-66 Rev. 2 are free starting points for structuring the work. Confirm internally who signs the addressable decision, because the organization, not a contractor, remains responsible for it.
What does the work need from our organization before it starts?
The work needs an accurate picture of your systems and an owner who can make decisions. Before starting, gather:
- A current inventory of systems and interfaces that send ePHI, including third-party connections
- The most recent HIPAA risk analysis and risk management plan, if one exists
- Network diagrams, certificate and key management ownership, and change control procedures
- Named approvers for the addressable decision and for any alternative measure
Missing inventory is the most common reason the scope grows during the engagement. Ask a provider to list these inputs in the written scope.
How long does transit integrity work typically take?
Duration is driven by dependencies rather than a fixed number, so ask for a timeline tied to them. The main dependencies are how quickly the ePHI inventory is completed, whether legacy systems can be upgraded or need an alternative measure, the change windows of the systems involved, and how many third parties must agree to new interfaces. Work on a single application with an existing TLS setup moves faster than a multi-site environment with custom protocols. Any written schedule should name each dependency and the party responsible for clearing it.
Does encryption alone satisfy the integrity specification for transmitted ePHI?
No, not automatically. Encryption protects confidentiality, while this specification addresses whether ePHI is improperly modified without detection in transit. Some encryption modes and protocols provide integrity protection as part of their design, and the entity must confirm that the chosen configuration does so for every path. Where a path uses weak or legacy protocols, or where the design lacks message authentication, the entity must either add a mechanism or document why it is not reasonable and appropriate and implement an equivalent alternative. Review your transport settings against the specification text in 45 CFR 164.312(e)(2)(i) rather than assuming that encryption closes the gap.
Does a third-party assessment prove HIPAA compliance?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that a certification does not prevent HHS from later finding a violation. An independent assessor can test whether your transit controls work as documented and report its findings, but that report is evidence for your own program, not a HIPAA certificate. Ask any assessor to state in writing what its work covers and what it does not. Implementation partners, including DeployOpen, prepare systems and evidence; they do not issue audit reports or certifications.
What enforcement risk comes with weak transit integrity controls?
The Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 audits review compliance with provisions most relevant to hacking and ransomware. Penalties are inflation-adjusted each year. For penalties assessed on or after January 28, 2026, the civil money penalty for a violation ranges from $145 per violation (no knowledge) to $2,190,294 per violation (uncorrected willful neglect), with a calendar-year cap of $2,190,294 (45 CFR 102.3). The exposure is greatest when an entity cannot show a documented decision for an addressable specification.
Which open-source tools can help produce evidence for transit integrity?
Open-source tools can support the configuration and evidence, but none of them satisfies the specification alone. Options include OPNsense, a stateful packet filter whose rules can be logged for review, to restrict which paths carry ePHI. Coraza, a web application firewall compatible with ModSecurity rulesets, can protect web entry points. FreeIPA's integrated certificate authority and the OpenBao PKI secrets engine can issue certificates for services. Confirm each tool's capabilities against its documentation in your environment before relying on it, and record the configuration as evidence.
How DeployOpen scopes and prepares transit integrity evidence
DeployOpen plans and builds the transit protections behind 164.312(e)(2)(i) Integrity controls inside your own infrastructure, then documents the configuration and evidence so your team and any independent assessor can review it. The organization owns its controls and its risk decisions, and only an independent auditor or assessor issues any report.
How we scope
- Written scope lists every network path that carries ePHI, including web, API, email and admin traffic, before work starts.
- Scope records which addressable choices your risk analysis supports, and which ones need a documented alternative measure.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.
How we build
- Integrity checks are placed where ePHI crosses boundaries, such as a Coraza web application firewall in front of ePHI-facing applications.
- OPNsense rules restrict which sources and ports can reach ePHI systems, with logging enabled for each rule match for review.
- Certificates for services are issued through FreeIPA or OpenBao PKI, so endpoints present verifiable identities for their connections.
How we hand over
- Configuration files, rule sets and certificate policies are documented so your team can reproduce and explain each transit control.
- Test results show that modified or unexpected requests are blocked or logged, with the exact test cases recorded.
- The handover names the evidence an assessor would ask for, and states which items remain your responsibility to maintain.
How we support
- Rule sets and certificate settings are reviewed when systems change, so the documented controls keep matching the running systems.
- Upgrades to Coraza rule sets, OPNsense and certificate components are planned and tested before they reach production.
- Retainers can cover periodic security testing of ePHI-facing transit paths, with findings tracked to closure in your own records.
