164.312(e)(1) Transmission security: what to prove

Transmission security under HIPAA: what the standard asks and why it is hard

If you must prove that electronic protected health information stays protected while it moves across networks, 45 CFR 164.312(e)(1) is the standard you are answering to. It requires technical security measures that guard against unauthorized access to ePHI transmitted over an electronic communications network. The standard has two implementation specifications, integrity controls under 164.312(e)(2)(i) and encryption under 164.312(e)(2)(ii), and both are *addressable*. Addressable means you must assess whether each specification is reasonable and appropriate for your environment, implement it if it is, and otherwise document why not and adopt an equivalent measure if one is reasonable. The risk being addressed is straightforward: someone intercepts ePHI in transit or modifies it without detection before it reaches its destination.

There is no HIPAA certification for this or any other Security Rule standard. HHS states that no standard requires an entity to certify compliance and does not recognize private certifications. The organization owns the control. An independent assessor can test it and report on what they find, and OCR judges compliance during an investigation or audit. Any vendor or consultant who sells a HIPAA certificate for transmission security is selling something HHS does not recognize. Ask an assessor to describe the evidence they will sample, not the badge they will issue.

The hard part is rarely the choice of TLS. It is finding every path ePHI takes. Web portals, patient messaging, email notifications, API integrations, VPN tunnels, file transfers, database replication and links between internal services all carry ePHI, and each can be configured differently. Legacy interfaces, a faxed-to-email gateway, or a scheduled export that a former employee set up may run without a current owner or diagram. Start by building a list of transmission paths from the risk analysis and interface inventory, then check each path for protection, its configuration owner and whether it is documented. Confirm the current TLS and VPN configurations with your own engineers, since the NIST resources that HHS lists as informational give the technical detail.

Which transmission paths and third parties fall in scope for this standard

Under 164.312(e)(1), scope starts with one question: does this path carry ePHI? Each path below changes the work in a different way, from encryption configuration to contract coverage. NIST SP 800-66 Rev. 2 is informational, not legally binding, so use its key activities as a working method rather than a checklist the rule itself imposes.

Patient-facing web and portals

Any page where a patient logs in, books an appointment, pays a bill or views results carries ePHI in both directions. Scope the full path, including the load balancer, the reverse proxy and any third-party scripts or widgets loaded on the page. Confirm that every hop serving these pages uses encrypted transport, and check whether marketing pages that never touch ePHI can be separated from authenticated areas. The authenticated portal is in scope even when a vendor hosts it.

APIs and system integrations

Interfaces between the EHR, labs, billing and patient apps exchange ePHI in structured messages, often without a person watching. Inventory every endpoint, the data each one returns and the service accounts that call it. Decide per integration whether traffic crosses a trust boundary, such as a public network or a partner network, since that boundary usually determines the encryption and integrity controls you must document.

Email carrying ePHI

Email is a frequent source of ePHI exposure because messages often leave the organization without encryption and sometimes reach mailboxes outside any controlled system. Identify where staff send clinical or billing content, whether automated notifications include patient details and whether the mail platform enforces transport encryption to known partners. Document how messages to unknown recipients are handled, since that decision is part of the transmission security record.

Remote access and VPNs

Staff, contractors and on-call clinicians who reach ePHI systems from home or other sites create paths that run over networks the organization does not control. Scope the VPN tunnels, remote desktop gateways and jump hosts that terminate these sessions. Confirm which protocols and cipher configurations are in use, and whether split tunneling lets ePHI-bearing sessions share a path with untrusted traffic. Reference NIST SP 800-77 and SP 800-113 as informational guidance for IPsec and SSL VPNs.

Internal service-to-service traffic

Traffic between application servers, databases and backup systems inside the data center or private cloud is often assumed to be safe. Scope it anyway when the link carries ePHI, because the risk analysis decides whether internal segments need protection. Check where replication, message queues and log shipping move ePHI, and whether certificates for those services are issued and rotated by a managed authority rather than by hand.

Vendor and business associate connections

Any external party that receives, transmits or hosts ePHI on your behalf is a business associate, and its connections fall within the rule's reach. Confirm that a business associate agreement is in place before data flows, and map each vendor connection to a documented transmission method. Subcontractors that the business associate uses to move ePHI must also be covered by written agreements. A vendor link without a signed agreement is a scoping gap, not only a contract issue.

How an assessor tests transmission security

This table compares each test area an assessor typically covers for 164.312(e)(1), what the assessor does, the evidence to have ready, and the findings that show up most often. Read it as a pre-assessment checklist: each row is a place where an organization should be able to show its work before an auditor asks.

Test area	What the assessor does	Evidence requested	Common findings
ePHI transmission path inventory	Confirms every route ePHI takes off-system, including EHR interfaces, email, file transfers, APIs, remote access and backups	Current data flow diagrams, interface register, network diagrams tied to ePHI systems	Paths missing from the inventory, such as vendor integrations or staff email to personal devices
Transmission security policy and procedures	Checks that written rules cover how ePHI may be sent, by whom and over which channels	Approved policy, procedure owners, review dates, staff acknowledgments	Policy exists but does not name channels or approved tools, or was never reviewed
Addressable specifications assessed and documented	Looks for a recorded decision on integrity controls and encryption, including the reasoning for any exception	Risk analysis entries, documented decisions, description of equivalent alternative measures where used	No documented decision, or a justification that does not hold up against the risk analysis
Integrity controls on transmitted data	Tests whether mechanisms detect unauthorized modification of ePHI in transit	Configuration of message signing, checksums, hash validation or protected channel settings	Integrity assumed from encryption alone with no check of how changes would be detected
Encryption on each path (TLS)	Reviews protocol versions, cipher suites and certificate validation on each endpoint, and whether clients reject invalid certificates	Scan output, server and load balancer configuration, certificate inventory with issuer and expiry, validation settings in client code	Legacy protocol versions still enabled, expired or self-signed certificates accepted, or internal services left unencrypted
Encryption on each path (VPN)	Checks VPN gateway settings, key exchange and authentication, and that remote access sessions are actually tunneled	Gateway configuration export, policy for approved VPN profiles, session logs	Split tunneling or weak legacy settings enabled without a documented reason
Sampling of traffic and configuration	Selects a sample of paths and traces them end to end, comparing configuration with what the inventory says	Packet or session captures where lawful and approved, change records, configuration snapshots for chosen paths	Sampled path behaves differently from its documented configuration, or changes were made without review

Implementing transmission security in six steps

This sequence turns the transmission security standard into a documented, configured and monitored set of controls, with each step producing an artifact an assessor can review. It follows the order most teams find workable: know where ePHI moves, decide on each addressable specification, write the rules, configure, watch for drift, and keep the evidence.

Inventory every ePHI transmission path
Start by listing each route ePHI takes over an electronic communications network: EHR-to-lab interfaces, patient portal sessions, email with clinical content, API calls between applications, VPN tunnels to remote staff, backups replicated to other sites, and connections to business associates. For each path, record the sending and receiving systems, the protocol, the network segment it crosses, and who owns it. The output is a path inventory that the risk analysis can reference. The security official or platform engineering lead typically owns it, with application owners confirming their entries. The step is done when someone outside the project can pick any path and find its owner, protocol and endpoints in the inventory.
Assess and record each addressable specification
For each path, decide whether integrity controls and encryption are reasonable and appropriate, based on what the risk analysis found about threats such as interception or modification. Where the entity does not implement a specification, document why and what equivalent measure is used instead, as the addressable rule requires. The output is a signed decision record per path, dated and approved by the security official. Compliance leads usually draft these records and technical owners supply the facts behind them. The step is complete when every path has a recorded decision that an assessor can trace back to the risk analysis.
Set the transmission security policy and procedures
Write the policy that governs how ePHI leaves systems: which protocols are permitted, which are prohibited, when encryption is mandatory in practice, how certificates and keys are issued and rotated, and who may approve exceptions. Procedures should explain how staff and engineers send ePHI by email, file transfer and API, and what to do when a path cannot meet the standard. The output is a version-controlled policy with named owners and a review date. The security official approves it and leadership acknowledges it. The step is done when the written policy matches the decision records from the previous step.
Configure encryption and integrity on each path
Implement the decisions. For web, API and email traffic this usually means TLS with current protocol versions and certificate management, and for site-to-site or remote access it means IPsec or SSL VPN configuration. Integrity controls can rely on the protection built into those protocols or on additional message authentication where the decision record calls for it. Certificate issuance can be automated with an internal certificate authority such as the Dogtag-based CA in FreeIPA, or with the OpenBao PKI secrets engine, which issues X.509 certificates to services without manual key and signing requests. Infrastructure engineers own the configuration. The output is a configuration baseline per path, stored in version control, that shows the cipher suites, protocol versions, certificate authorities and rules in force. The step is done when each path's live settings match its baseline.
Monitor and log configuration and rule changes
Turn on logging for the components that carry ePHI traffic, including firewall rule matches, VPN session events, reverse proxy and web application firewall events, and certificate issuance. OPNsense can log each rule match for review in its live log view, and Coraza can record blocked requests when run with a ModSecurity-compatible ruleset in front of web applications. Tune the logs so they capture changes to rules, protocols and certificates, not just traffic. Platform engineers configure the collection and the security team reviews it on a schedule the entity sets. The output is a log source list, a review record, and alerts for configuration drift. The step is done when a change to a transmission rule leaves a trace that someone reviews.
Retain evidence on a recurring schedule
Set up a recurring cycle that collects evidence and rechecks the earlier steps: refreshed path inventories, re-signed decision records when systems or risks change, configuration baselines compared against live settings, and samples of logs showing reviews. Tie the cycle to the risk analysis update process so new paths are added when systems change. Retain the records under the documentation requirements that apply to the entity. The output is an evidence binder or repository with dated entries and a named owner for each item. The security official or compliance lead runs the cycle. Ask any third-party assessor what sample of evidence they expect before the review begins, because the format they accept may differ from internal records.

Which evidence passes an assessment and how to keep it current

Evidence for 164.312(e)(1) has to show that transmission protections operate day to day, not only that a policy exists. The cards below cover the artifacts assessors ask for, how often each one needs refreshing between audits, and who should review or sign it, so that your records stay consistent with the systems they describe.

Transmission path inventory

This is a current map of every route ePHI takes over a network, including web portals, APIs, email gateways, VPN tunnels, backup replication, and links to business associates and clouds. Assessors use it to test whether every path was considered in the risk analysis and whether the encryption and integrity decisions cover each one. Refresh it whenever a new interface, vendor connection or network segment appears, and review it at least once a year. Ask the system owner and the security official to sign off, and check that it matches the firewall and load balancer configurations.

Addressable specification decisions

For integrity controls and encryption, the rule requires a documented decision on whether each specification is reasonable and appropriate. Where you decline encryption, the record must explain why and name the equivalent measure. Keep one dated decision record per path, with the risk analysis reference and the reviewer's name. Revisit each decision when the threat picture, the data sensitivity or the proposed rule changes, since the 2025 proposal would make encryption mandatory. The security official should approve these records.

TLS and VPN configuration baselines

Baselines record the protocol versions, cipher suites, certificate settings and VPN parameters you chose, with the NIST publications you used as a reference, such as SP 800-52 for TLS or SP 800-77 for IPsec VPNs. Store them in version control so every change has an author, a reason and an approval. Assessors compare live settings against the baseline and read the change history to confirm controls were not weakened without review. Re-scan endpoints on a regular schedule and after each platform upgrade, and keep the scan output with the baseline.

Certificate inventory and renewal records

A certificate inventory lists every certificate protecting ePHI in transit, its issuer, the hosts it covers, its expiry date and the person responsible for renewal. Renewal records show when each certificate was issued or rotated and whether the replacement passed the baseline checks. Expired or unknown certificates are a common cause of failed transmissions and an easy finding for an assessor. Reconcile the inventory against live scans at least monthly, and have the operations owner confirm it before each audit window.

Firewall rule sets with match logs

Rule sets show which sources, destinations, ports and protocols are allowed to carry ePHI, and why. Logs of rule matches prove the rules run as written, which is what an assessor tests when reviewing integrity and transmission protections. Export the rule set on each approved change and retain it with the change ticket. Review denied and unexpected matches on a defined cadence, and document the reviewer's findings. Confirm with your platform team whether your firewall keeps logs of rule matches and for how long.

Policy approval records

Transmission security policies and procedures need evidence of who approved them, when, and what changed since the last version. Keep signed approval records with version numbers, and tie each review to an actual operating activity, such as a quarterly baseline check or an annual path inventory review. Assessors look for evidence that policies are followed, so reviews should reference the artifacts above. Confirm the retention period for these records against the documentation requirements that apply to your organization.

Which self-hosted open-source tools produce transmission security evidence

Coraza is an open-source web application firewall licensed under Apache-2.0. It is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it defends against attacks such as SQL injection, cross-site scripting and code injection. It integrates with Caddy, HAProxy, Traefik and Nginx, so it can sit in front of the web and API services that move ePHI. For transmission security, its output is useful evidence that inbound requests are inspected and that blocked or logged events are recorded. It does not show that the connection itself is encrypted or that the traffic is protected on the path between systems.

Rule configuration: Exported SecLang rule sets and the OWASP Core Rule Set version in use show what traffic is inspected.
Audit logs: Blocked and matched requests recorded by the WAF can support review of attempted attacks against ePHI endpoints.
Proxy integration: Configuration for the chosen proxy (Caddy, HAProxy, Traefik or Nginx) shows where Coraza sits in the request path.
TLS termination settings: The proxy configuration that handles TLS, including protocol versions and cipher settings, is separate evidence and must be captured.
License obligations: Confirm Apache-2.0 notice and attribution requirements for your distribution and any modifications.

Confirm with your security team which endpoints carry ePHI, whether the WAF sits in front of every one of them, and whether TLS is enforced end to end, including on internal hops.

What meeting transmission security costs in money and effort

This table breaks down the cost components of meeting 164.312(e)(1) for ePHI in transit, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to reduce it. Use it to frame a written quote, since no supplied figures give prices or durations for this standard. The main takeaway is that open-source software removes license spend but not the engineering, certificate and evidence work that an assessor will test.

Cost component	One-time or recurring	What drives it	How to reduce it
Engineering time for path inventory and TLS or VPN configuration	One-time for the first pass, recurring for changes	Number of systems, external interfaces, legacy protocols and third-party links that carry ePHI	Inventory data flows once from the risk analysis, then standardize on a small set of approved TLS and VPN profiles
Tooling and licenses	Recurring where commercial products are used	Commercial VPN, gateway or monitoring licenses; open-source options such as OPNsense or Coraza remove license spend but not staffing	Ask whether self-hosted open-source components meet the need, and price support contracts separately from software
Certificate operations	Recurring	Certificate count, renewal frequency, key lengths and whether a private CA such as FreeIPA or OpenBao PKI is run in house	Automate issuance and renewal so certificates are not renewed by hand, and document the CA owner
Evidence upkeep	Recurring	How often configurations change, how many systems are in scope and how much proof must be retained under the six-year documentation rule in 164.316	Generate configuration exports and scan results on a schedule, and store them in one evidence location
External penetration or configuration review	Recurring, typically annual or after major change	Exposed endpoints, scope of testing, retest requirements and whether the test covers TLS settings and VPN configuration	Define the scope in writing, test the same endpoints each cycle and fix findings before the retest
Auditor or assessor time	Recurring per assessment cycle	Number of entities, systems and interfaces sampled, and how well the evidence is organized	Prepare an evidence map that links each specification to artifacts before the assessor arrives
Penalty exposure (for context only)	Not a cost of compliance	Under 45 CFR 102.3, the inflation-adjusted civil money penalty for violations ranges from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294	Treat transmission security as a funded control, since weak transit protection is a direct source of exposure

Who does what: your team, a partner and the assessor

Your organization owns the safeguard. The Security Rule places the obligation on the covered entity or business associate, so the decisions about which network paths carry ePHI, which protocols are acceptable, and whether an addressable specification is reasonable and appropriate belong to you. A partner can recommend, but cannot accept the residual risk for you.

Transmission security policy: Your team writes and approves the policy and procedures that define which channels may carry ePHI and what protection each channel requires.
Risk decisions: Your risk analysis determines whether integrity controls and encryption are reasonable and appropriate for each data flow, and documents the reasoning and any equivalent alternative.
Business associate relationships: Your team keeps the agreements with vendors and hosting providers that transmit ePHI, and confirms what those parties protect in transit.
Operational ownership: Staff review logs, rotate keys, track certificate expiry and respond when a channel fails its requirements.
Evidence custody: Your team retains the configurations, approvals and records that an assessor will request.

Check that your policy names an accountable owner for each channel and that the risk analysis covers every data flow, not only the public-facing ones.

Where transmission security audits usually fail and how to close each gap

Transmission security findings tend to cluster around a few predictable blind spots: data paths nobody mapped, addressable decisions nobody recorded, and protocols nobody retired. Each card below names one gap, the fix that closes it, and the evidence an assessor will ask to see. Your organization owns the controls; an implementation partner can help prepare the systems and records, and only an independent assessor can test and report on them.

Unknown transmission paths

Shadow integrations, forgotten SFTP jobs and email relays set up by a single department often carry ePHI outside the systems the risk analysis describes. An assessor will ask where ePHI leaves your environment and whether each path was identified as a source that could intercept or modify it. Fix this by building a data flow inventory that starts from the risk analysis and walks every interface, relay and batch job. Evidence that it is closed is a dated diagram or register with an owner for each path, plus scan results showing no unlisted endpoints receiving ePHI.

Addressable specifications with no decision

Encryption and integrity controls under 164.312(e)(1) are addressable, which means the entity must assess whether each is reasonable and appropriate. Many audits fail not because a control is missing but because no one recorded the assessment. If a measure is not implemented, the file should show why and what equivalent alternative was used. Evidence that closes this gap is a signed decision memo for each addressable specification, tied to the risk analysis, reviewed on a set schedule and updated when the architecture changes.

Legacy protocols and weak ciphers

Plaintext FTP, Telnet, SSL-era ports and older TLS versions often stay enabled on load balancers, mail gateways and appliances long after the application moved on. An assessor will scan the externally and internally reachable services that carry ePHI and check protocol versions and cipher suites against your transmission security policy. Fix this by disabling deprecated protocols, setting a minimum TLS version and documenting the approved cipher list, with NIST SP 800-52 as a reference. Evidence is a scan report from before and after the change, with the configuration baseline checked into change control.

Certificates without renewal records

Expired certificates break encrypted sessions and often push teams to disable validation, which quietly removes the protection the encryption was meant to provide. Assessors look for an inventory of certificates protecting ePHI links, the owner of each, and a record of renewals. Fix this with a central certificate authority or automated issuance, so renewals and key rotation leave an audit trail. Open-source options such as the OpenBao PKI secrets engine can issue short-lived X.509 certificates, and FreeIPA includes a Dogtag-based certificate authority. Evidence is the inventory, issuance logs and alerts for upcoming expirations.

Internal traffic assumed safe

Teams often encrypt traffic at the internet edge and treat the data center or cloud VPC as trusted, leaving ePHI moving in clear text between application, database and backup hosts. The transmission standard applies to ePHI on any electronic communications network, so an assessor will ask about internal segments that carry ePHI. Fix this by mapping internal flows, enforcing TLS or IPsec on sensitive east-west traffic where the risk analysis calls for it, and restricting paths with firewall rules that log matches. OPNsense rules can filter by source, destination, port and protocol, and log each match for review. Evidence is the flow map, rule set and sample log records.

Vendor links without documented encryption

Clearinghouse feeds, SaaS connectors, billing portals and support tunnels run under vendor-controlled settings that the covered entity may never have reviewed. Assessors ask for the encryption method used on each vendor link and whether the contract or business associate terms address it. Fix this by collecting the transmission details from every vendor, confirming the protocol and key handling in writing, and recording exceptions with a decision. Evidence is a vendor transmission register that cross-references business associate agreements and shows that each link was confirmed during the most recent review.

Questions buyers ask about transmission security cost, effort and outside help

How much work does it take to meet 164.312(e)(1) transmission security?

The work scales with how many paths carry ePHI, not with the rule text itself, which is short. Start by listing every channel that moves ePHI outside a single system: web portals, APIs, email, file transfers, database replication, backups sent offsite, VPN links between sites and connections to business associates. For each path, the entity must identify who could intercept or modify the data, document a transmission security policy, decide how integrity will be protected and implement encryption where it is appropriate. Most of the effort is inventory, configuration review and change control, not new software. Ask any consultant or partner to price the work from a written list of paths and systems.

Can a small team meet transmission security without an outside partner?

Yes, a small team with someone who understands TLS, VPNs and mail configuration can do much of it in-house. The standard is addressable, so the team must justify every decision in writing, and that documentation is where small teams often struggle. An in-house team usually needs time to map ePHI flows, test configurations and keep the policy current as systems change. Outside help is most useful for the network design review, a second opinion on the risk analysis and hardening of systems the team has not run before. Whichever route you choose, the covered entity or business associate remains responsible for the decisions.

How long does it take to meet transmission security controls?

Duration depends on the number of transmission paths, how many systems each path touches, and whether the environment is cloud, on-premises or air-gapped. A narrow environment with a few well-documented paths takes far less time than a multi-site network with legacy interfaces. Any figure should come from the written scope, which lists the paths, the deliverables such as configuration baselines and policy documents, and the change windows needed for production work. Ask the partner to state its assumptions about path count and to name which items the client must complete before work starts.

Does encryption alone satisfy the transmission security standard?

No. Encryption is one of two addressable implementation specifications under 164.312(e)(1), and the other is integrity controls, which protect ePHI from undetected modification in transit. An entity that encrypts all traffic but never identifies who could intercept or alter the data, or never documents its transmission security policy, still has gaps. Encryption also has to be configured correctly: weak protocol versions, expired certificates and unmanaged keys can defeat it. Assessors look for the full set of key activities in NIST SP 800-66 Rev. 2, not just a TLS setting.

What does the work need from our team?

The work needs named system owners who can confirm what each system does with ePHI and which data crosses which boundary. It also needs administrative access to the relevant configurations, such as web servers, load balancers, mail gateways, VPN concentrators and certificate stores, plus approved change windows for anything that touches production. Your security official should own the policy and the risk decisions, and someone should be available to review exceptions when an addressable specification is set aside. Ask the partner to list these dependencies in the written scope so that delays are visible early.

Is there a HIPAA certification for transmission security?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private certifications. Any vendor or consultant offering a HIPAA certificate is selling an opinion or a badge, not a finding that binds HHS. What HHS can review is whether your documented decisions, configurations and evidence match what the rule requires. An independent assessor can test and report on controls, but that report does not prevent a later OCR finding.

What would the 2025 proposed rule change for encryption in transit?

HHS proposed on January 6, 2025 (90 FR 898) to make encryption of ePHI in transit a required rather than addressable specification, and it has not been finalized. If the proposal were adopted as written, entities would no longer be able to document a decision to forgo transmission encryption on the basis of reasonableness. The proposal's status is tracked in the Unified Agenda entry for RIN 0945-AA22, which lists final action as a long-term action. Plan your current controls against the existing text, and confirm the final status with counsel before relying on any projected date.

What can a partner not do for an assessor?

A partner cannot issue an audit report, attestation or certificate, and it cannot decide that your organization is compliant. Its role is to prepare systems, configurations and evidence, and to document how they map to the standard. Independent auditors or assessors are the only parties who can test the controls and report on them. The covered entity or business associate still owns its risk analysis, its policy decisions and any statement it makes to OCR, its customers or its regulators.

How DeployOpen scopes and prepares transmission security evidence

DeployOpen approaches 164.312(e)(1) as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before any work starts. The work is delivered inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks, so the ePHI paths, keys and logs stay under the organization's control. The covered entity or business associate owns the transmission security policy and the risk decisions behind it. DeployOpen prepares the systems and the evidence that support those decisions. It does not issue audit reports, attestations or certifications, and HHS does not recognize any private HIPAA certification.

The first deliverable is usually a path inventory: every channel over which ePHI moves between users, applications, APIs, partners and self-hosted platforms, including the protocols and endpoints on each. From that inventory, DeployOpen hardens the self-hosted platforms that terminate or relay traffic, configures packet filtering on OPNsense rules with aliases for known partner networks and logging on rule matches, and sets up Coraza as a web application firewall in front of ePHI web services. It also automates certificate issuance with FreeIPA's Dogtag-based certificate authority or the OpenBao PKI secrets engine, so TLS certificates are renewed without manual steps. The client's team should confirm which of these components they already run before scoping.

Evidence is assembled as the work proceeds: configuration exports, rule sets, certificate inventories, test results and the documented decisions on each addressable specification, including any equivalent alternative measure. Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered. Quotes follow from the written scope, and DeployOpen does not publish a price list. Ask for the scope to name the specific paths, platforms and evidence items it covers, so the quote and the assessor's questions line up.

164.312(e)(1) Transmission security