09 Transmission Protection in HITRUST CSF: evidence guide

What HITRUST 09 Transmission Protection asks you to prove

Transmission Protection is the HITRUST assessment domain that covers data in transit: the encryption on application endpoints, the secure exchanges with third parties, and the certificates that make those connections trustworthy. If an assessment is coming and your transit encryption story is unclear, start by listing every path that carries in-scope data between systems, users, partners and providers. Each path needs an answer to three questions: is it encrypted, which protocol and configuration is in use, and who owns the certificate behind it. The risks are the familiar ones. Traffic can be intercepted, a connection can be downgraded to weak or obsolete protocol versions, and a server or partner can be impersonated when certificates are missing, expired or unverified.

The difficulty is rarely the cipher. It is the inventory. Legacy endpoints still accept old protocol versions because nobody has retired them. Certificates expire on a date that no one tracks because the person who requested them has left. Partner file transfers and API links were configured years ago, with settings no current team can explain. Each of these is a gap an assessor can find by sampling a few connections and asking for the configuration and the owner. This is one of the 19 domains that HITRUST scores in e1, i1 and r2 reports, so weak evidence here lowers the domain score rather than being a footnote.

HITRUST's own example for the Oracle Cloud Infrastructure inheritance case treats Transmission Protection as moderately inheritable. The provider enforces TLS in its backbone and can offer managed certificates, while the customer still has to enforce HTTPS and TLS on its own endpoints and on partner exchanges. Before you rely on any provider statement, confirm in writing which certificates, endpoints and partner links fall on each side of that line. Then assign an owner and a renewal process to each customer-side item. The HITRUST inheritance blog post explains the example, and the boundary you document there becomes the boundary your assessor tests.

Which endpoints, partner links and certificates fall in scope for transmission protection

Transmission protection covers every path where in-scope data leaves one system and enters another. The assessment boundary decides which of those paths count, and inheritance from a cloud provider decides who owns each one. The cards below cover the decisions that change the work.

Public and internal application endpoints

Every HTTPS listener that serves in-scope data is in scope, including public websites, customer portals and internal admin consoles. Check redirects from HTTP, cipher and protocol settings, and whether internal services reached by staff on corporate networks still use TLS. Teams often assume internal traffic is safe and leave it outside the inventory, which is where gaps tend to appear.

APIs and service-to-service connections

APIs, message brokers and database connections carry in-scope data between components, often without anyone reviewing them as network links. List each client and server pair, confirm that certificate validation is enabled on both sides, and record which connections are internal to a cluster and which cross a network boundary. Service meshes and sidecars can change where encryption happens, so document that choice.

Database connections and data stores

Connections from application servers to databases, caches and search indexes are in scope when they carry protected data. Check whether the driver enforces encrypted sessions and verifies the server certificate, not just whether encryption is available. Managed database services often provide TLS on their endpoints, so confirm with the provider which parts of the connection the customer must configure.

File transfer with third parties

Secure file transfer, SFTP endpoints, API uploads and data feeds to partners, processors and regulators form the partner-facing part of the boundary. Record the protocol, the minimum version the partner accepts and who manages the certificates on each side. Partner links are often configured by an integration team and absent from the architecture diagram, so the register should come from the network and integration records, not memory.

Email and admin access paths

Mail submission, mail retrieval and administrator access paths such as SSH, remote desktop and management consoles can each carry sensitive data or credentials. Confirm that opportunistic or enforced TLS is set for mail relays, and that admin sessions use encrypted protocols only. Jump hosts and bastion services sit on the boundary between access control and transmission protection, so assign them a clear owner in the assessment.

Certificate authorities and certificate lifecycle

The certificate authority that issues the certificates is part of the scope, along with the process for issuing, renewing and revoking them. Identify whether certificates come from a public issuer, an internal CA or a cloud provider's managed service, and who holds the signing keys. An expired certificate on an in-scope endpoint is a transmission failure, so the inventory should list expiry dates and renewal owners.

How an assessor tests transmission protection

This table compares each area an assessor examines for the 09 Transmission Protection domain, the test method used, the evidence requested and the findings that most often appear. Read it as a checklist of what to prepare before fieldwork, since every row maps to a question the assessor will ask.

Test area	What the assessor does	Evidence requested	Common findings
Sampled endpoints	Selects a sample of in-scope HTTPS endpoints and internal services that carry sensitive data, then checks each one	Endpoint inventory with owners, data classification per endpoint and the sampling population the assessor drew from	Endpoints missing from the inventory, so they were never tested
Protocol and cipher settings	Scans or reviews server and load balancer configuration for protocol versions and cipher suites in use	Scan output or configuration exports, dated near fieldwork, with the approved protocol and cipher standard	Older protocol versions still enabled on a load balancer or legacy service
Certificate inventory and renewal	Compares certificates in use against the inventory and checks expiry dates and renewal records	Certificate register, issuing authority for each certificate, renewal logs and alerting configuration	Expired certificates, or certificates in use that no one recorded
Partner exchanges	Reviews agreements with third parties that receive or send in-scope data and checks the stated encryption requirement	Signed partner or data sharing agreements, connection configurations and the encryption method for each link	Partner links with no stated encryption requirement in the contract or configuration
Internal traffic	Asks how traffic between internal services is protected and whether that protection is documented	Architecture diagrams showing data flows, documented internal encryption decisions and configuration samples	Undocumented internal traffic that crosses network zones in clear text
Exceptions	Inspects every exception to the transmission standard, including its approval, compensating measures and review date	Exception register with approver, risk acceptance, expiry and evidence of periodic review	Exceptions with no expiry or no approval on record
Fieldwork boundaries	Completes validated fieldwork within a bounded window and tests a defined sample rather than every endpoint	Agreed scope, sampling method and a fieldwork schedule shared before testing starts	Late evidence requests that disrupt the window and push testing into re-work

How to implement transmission protection step by step

This sequence takes an organization from knowing every path its data crosses to a documented, enforced and tested state for 09 Transmission Protection. Each step produces a record an assessor can sample, so the evidence builds as the work proceeds.

Inventory every in-scope transit path
Map each route data takes between users, applications, services, databases, backups and external parties inside the assessed scope. Include load balancers, API gateways, service meshes, admin consoles and message queues, not only public web endpoints. The owning team signs off the list, and the output is an endpoint and data flow inventory that names each path, its protocol and its owner. The step is done when the inventory matches the architecture diagrams and the scope statement used for the assessment.
Set and document a TLS baseline
Write a transmission standard that states which protocol versions, cipher suites and key lengths are permitted, which are banned, and how plaintext fallback is blocked. Security engineering approves the standard, and platform teams translate it into configuration for each endpoint class. The output is the approved TLS standard plus a configuration record for each service. Confirm current recommended settings with your standards body or your tool vendor before you lock the baseline, because these change over time.
Enforce the baseline at endpoints and proxies
Apply the standard to every listener, reverse proxy, load balancer and gateway in the inventory, and redirect or refuse plaintext HTTP where the application does not need it. Internal hops that cross trust boundaries are covered by the same rule. Platform engineers make the change through version-controlled configuration so that drift can be detected. The output is a scan or configuration export showing each endpoint against the standard, with exceptions recorded and approved.
Establish a certificate authority and issuance policy
Decide which certificate authority issues internal and public certificates, who may request them, which names and key types are allowed and how revocation is handled. Public certificates may come from a commercial or public CA, while internal services often use a private CA run on the organization's own infrastructure. Governance owns the policy and the security team owns the CA keys. The output is a written issuance policy and a documented chain of trust, which an assessor will read alongside the certificate register.
Automate issuance and renewal with named ownership
Move certificate creation and renewal into automation where the platform allows it, and record an accountable owner for every certificate. Automation reduces the chance of an expired certificate taking a service down, but each certificate still needs a human owner who answers for it. The output is a certificate register listing the name, issuer, expiry, owner, system and renewal method for each certificate. Check the register against the endpoint inventory so that no in-scope endpoint lacks an entry.
Define secure exchange requirements for third parties
For each partner, processor or customer that exchanges data with the environment, record the protocol, authentication method, certificate pinning or trust anchors where used, and the contractual obligation to keep transmissions protected. Third-party assurance reviews these records alongside vendor due diligence. The output is a partner exchange record for each connection, reviewed on a set schedule set by the organization. Where a provider already enforces transmission controls, note which parts are inherited and which remain with your team.
Monitor, test and close gaps
Run recurring scans of external and internal endpoints against the TLS standard, alert on certificates nearing expiry and on protocol downgrades, and test a sample of partner connections end to end. Findings feed the corrective action process, and each one is closed with a documented fix or an approved exception. The output is the scan history, expiry alerts, test results and a remediation log. Assessors sample this record, so keep it current and dated rather than assembling it before fieldwork.

What changed in CSF v11.9.0 for TLS, PKI and post-quantum planning

HITRUST CSF v11.9.0, released September 24, 2026, refreshed the technology-specific requirements for public key infrastructure, TLS and passkeys, and added post-quantum cryptography considerations to the framework. For the 09 Transmission Protection domain, this means the requirement statements that govern how your endpoints negotiate TLS, how certificates are issued and renewed, and how your authentication keys are handled may be worded differently from the version you last assessed against. Before you plan any remediation, confirm with HITRUST's release advisory, HAA 2026-005, and with your External Assessor which CSF version your validated assessment will be scored against.

The version question depends on your timeline and your assessment type. Ask your assessor whether an assessment already in incubation or fieldwork will be scored under v11.9.0 or an earlier version, and whether a renewal or interim assessment will move you to the new version. Then ask how the refreshed TLS and PKI language changes what evidence the assessor expects in your environment. The answer determines whether you need to update your certificate inventory, your cipher suite configuration and your documented certificate lifecycle before fieldwork begins, or whether the changes only affect how you describe controls you already run.

Post-quantum considerations are the change most likely to be misread as a current obligation. Treat them as a planning input: build a cryptographic inventory that lists every certificate, key type, TLS protocol version and cipher suite on your in-scope endpoints and partner exchanges, and record which algorithms would need replacing if post-quantum standards are adopted. Ask your team and your assessor what the framework expects you to show today versus what it expects you to have planned. Keep the inventory in your configuration management records so it can be updated at each CSF release.

Evidence that satisfies transmission protection

Assessors testing 09 Transmission Protection look for proof that every path carrying in-scope data is encrypted, that the settings are current, and that exceptions are owned and time-limited. The cards below cover the artifacts that prove this, and the routine checks that keep each one accurate between assessment cycles.

TLS scan results per endpoint

Keep a dated scan report for every externally reachable and internal endpoint that handles in-scope data, showing the protocol versions offered, cipher suites accepted and certificate chain status. Assessors compare these results against your written policy, so a scan that predates a configuration change proves little. Schedule scans on a fixed cadence and after every change to load balancers, ingress rules or application servers, and file each report with the scope it covered. Confirm that scans reach internal services, not only the public edge.

Protocol and cipher policy

Maintain one written policy that names the minimum TLS version, the approved cipher suites and the rules for key exchange and certificate validation. It is the yardstick every scan result is measured against, so it must be approved, versioned and dated. Review it when HITRUST releases a new CSF version, since v11.9.0 refreshed its technology-specific requirements for TLS and PKI. Record who approved each change and why, so the policy history can be shown to an assessor.

Certificate inventory with owners

Maintain a register of every certificate in scope, listing the hostname or service it protects, issuing authority, owning team, installation location and expiry date. An inventory without named owners leaves expiring certificates unassigned, which is a common reason outages and gaps appear together. Reconcile the register against live scan results at least quarterly, and remove certificates that no longer protect a live service. Assessors often sample entries from this list and trace each one back to a running endpoint.

Certificate renewal logs

Record each renewal with the old and new expiry dates, the issuer, the time of replacement and the person or automation that performed it. Automated renewal tools generate these entries, but you must retain them and confirm that failed renewals raise alerts. Renewal logs show that certificates are replaced before they lapse, not after a browser warning appears. Keep them for the retention period your policy sets, and check a sample each quarter to confirm the automation still runs.

Partner exchange agreements

Document how data leaves your environment for third parties, and the encryption each exchange requires. Contracts, data processing terms or interface specifications should name the protocol, minimum key length or cipher, and the endpoint details agreed with each partner. Where a partner cannot meet your standard, record it as an exception rather than leaving the gap undocumented. Review these agreements when a partner changes its endpoints, and link each one to the third-party risk record in the Third-party Assurance domain.

Internal traffic encryption design

Provide a design document that shows which internal flows carry in-scope data, such as service-to-service calls, database connections, backup transfers and administrative sessions, and how each is encrypted. Diagrams should match the deployed network, not the intended one. Update the design when you add a service, change a mesh or move a workload to a new cluster. Assessors use this document to decide which internal paths to test, so an undocumented path is a likely finding.

Exception records

Log every endpoint or flow that does not meet the transmission policy, with the technical reason, compensating controls, a named risk owner, an approval date and a review date. Exceptions with no expiry tend to become permanent gaps, and assessors question open-ended approvals. Review each exception on its stated date, close it when the endpoint is fixed, and confirm that the exception list matches the latest scan results. Treat any exception that touches regulated data as a risk decision that the owner must sign.

What meeting transmission protection costs in money and effort

This table breaks down the cost and effort components of transmission protection for a HITRUST assessment, showing who is paid, whether each item is one-time or recurring, and what drives it up. Use it to structure a quote request and to decide which items your own team can absorb. No fees or durations are stated because none were supplied; ask each party for its own figures.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
TLS scanning and monitoring tools	Tool vendor or your own staff; open-source scanners carry no license fee	Recurring (scan runs, monitoring, reporting)	Number of public and internal endpoints, and how often scans must run to evidence ongoing TLS checks
Certificate authority and PKI operation	Internal platform team, or a managed PKI provider if you buy one	Set-up one-time, operation recurring	Number of certificates, certificate lifetimes, and whether issuance is automated with cert-manager or FreeIPA
Secrets and key management	Internal team; OpenBao is open source under MPL-2.0 with no license fee, but operation has staff cost	Set-up one-time, operation recurring	Number of services that need encryption keys, key rotation frequency, and high availability design
Engineering time to fix endpoints and proxies	Your engineers, or an implementation partner under a written scope	One-time for remediation, some recurring for upkeep	Legacy estate, outdated protocol or cipher support, and the number of load balancers and reverse proxies
Partner and third-party exchange coordination	Your compliance and integration staff, plus the partner's staff	Largely one-time per link, with periodic review	Number of partner links, whether each uses a supported secure transfer method, and how many contracts must be updated
Evidence upkeep	Your control owners and operations staff	Recurring	Frequency of scan reports, certificate inventories, configuration exports and change records retained for the assessor
Readiness review	Internal staff, or a consultant or readiness licensee if you engage one	One-time before assessment	Breadth of in-scope systems and how much prior evidence exists for the domain
Assessor fees	Authorized HITRUST External Assessor organization	Per assessment, repeated at each validated assessment cycle	Scope size, number of sampled systems and partner links, and fieldwork window of up to 90 days

Who owns transmission protection and who can help

Your organization owns the controls. That means the policy that says which protocols and cipher standards are acceptable, the decision on which data flows must be encrypted in transit, the approval of third-party exchanges, and the accountability for how endpoints are configured and monitored. A partner can draft material and build systems, but the signed decisions and the people who operate the environment day to day belong to you.

Policy and standards: Set the approved TLS versions, cipher suite rules, certificate lifetimes and rules for plaintext fallback, and keep them under document control.
Data flow ownership: Identify every path that carries in-scope data, including internal service calls, customer portals, APIs and partner file exchanges.
Operational decisions: Decide who approves exceptions, who responds when a certificate is about to expire and how private keys are protected.
Third-party agreements: Confirm that counterparties accept the required transport standards in contracts and onboarding.
Evidence custody: Keep configuration exports, scan results and change records in a location your assessor can access.

Confirm with your assessor early which of these artifacts they will sample and for what period.

Where transmission protection assessments usually fall short

Transmission protection findings tend to cluster around ownership, lifecycle and undocumented defaults rather than missing technology. Each gap below is one a HITRUST assessor can test with evidence, and each has a concrete way to close it before fieldwork begins.

Certificates with no named owner

A certificate without an accountable owner is usually found when it expires, because nobody was assigned to watch it. Assessors look for an inventory that lists each certificate, the service it protects, the team that renews it and the issuing authority. To close this gap, record every externally facing and internal certificate in a register with a named owner, and tie each entry to a change or ticket record so ownership survives staff changes.

Expired or self-signed certificates in production

Self-signed certificates in production are a frequent finding because they bypass the trust chain that clients rely on, and expired certificates break connections or push teams toward disabling checks. Check whether production endpoints present certificates from an approved issuer and whether any were allowed to lapse. Automated renewal tooling, such as cert-manager for Kubernetes workloads, reduces the chance of lapses, but the renewal path still needs monitoring and a documented fallback.

Legacy protocols left enabled

Endpoints often keep older protocol versions and weak cipher suites enabled after newer ones are deployed, because disabling them was never scheduled. Assessors commonly test this with external scans and configuration exports from load balancers, web servers and API gateways. Close it by setting an approved protocol and cipher policy, disabling deprecated versions on every endpoint, and keeping scan results as evidence that the setting holds over time.

Internal service traffic left unencrypted

Teams often encrypt the internet-facing edge and assume traffic between services inside the network is safe, so service-to-service calls, database connections and message queues run in plaintext. Map every data flow that carries in-scope data, including those inside the cluster or data center, and confirm each one uses TLS or an equivalent protected channel. Where a flow cannot be encrypted, document the compensating control and the risk acceptance that covers it.

Partner exchanges on undocumented defaults

Partner integrations, such as SFTP transfers, API connections and file gateways, often run on whatever settings the software shipped with, and nobody recorded what was agreed. Assessors ask for the transport requirements in each partner agreement and the configuration that enforces them. Close the gap by documenting the agreed protocol, cipher and certificate pinning or trust settings for each partner, and reviewing them when the partner or the software changes.

No evidence of renewal

Teams often renew certificates correctly but cannot show it, so the assessor finds no record of issuance, renewal or key rotation during the review period. Keep logs of certificate issuance and renewal events, retain the reports from endpoint scans, and record key rotation in the change system. Ask your auditor which samples they will select so that the evidence covers the full period under test, not only the most recent renewal.

Questions buyers ask about transmission protection

How long does transmission protection work take for a HITRUST assessment?

No single duration applies to every environment, because the time depends on how many endpoints, partner exchanges and certificate paths sit in scope and how much of the current state is already documented. Inventory work usually runs first: listing every public and internal endpoint, every client that connects to it, every third-party exchange and every certificate authority in use. Enforcement changes follow, such as retiring older protocol versions and standardizing cipher configuration, and these often need change windows and application testing. Evidence collection comes last and needs enough time to show the controls operated before the assessor arrives. The validated assessment fieldwork window is at most 90 days for e1, i1 and r2 (HITRUST Assessment Handbook v1.1). Ask any partner to break its estimate into these phases and to state which of them depends on your change calendar.

Can an internal team handle transmission protection without a partner?

Yes, many internal teams do this work, provided they have someone who owns the TLS configuration of every in-scope endpoint and a documented process for certificate issuance and renewal. The harder part is usually evidence rather than engineering: showing the assessor a consistent record of configurations, scan results and certificate inventories over the assessment period. Teams that have not built this before often underestimate the number of endpoints that were set up outside standard processes, such as legacy integrations and vendor-managed appliances. An internal team should also confirm that its own readiness work is independent of the assessment itself, because only an authorized External Assessor performs the validated assessment. A partner can take on implementation and evidence preparation, but the organization still owns the controls.

What does the work need from engineering and security teams?

Transmission protection touches several groups, and each has a distinct job:

Platform and application engineers update TLS settings on load balancers, ingress controllers and services, and confirm that HTTPS is enforced end to end.
Security engineers set the approved protocol versions and cipher policy, review scan results and decide how exceptions are documented.
Integration owners inventory and reconfigure secure exchanges with third parties, including file transfer, API and message paths.
Operations staff own certificate issuance, renewal and revocation, and keep the inventory current.

Engineering effort concentrates on legacy clients that cannot negotiate modern TLS, since those often need either an upgrade or a documented, approved exception. Ask for a named owner in each group before work starts.

How does inheritance from a cloud provider change transmission protection effort?

Inheritance can reduce the work but does not remove it. In HITRUST's OCI inheritance example, transmission protection is moderately inheritable: the provider enforces TLS within its own backbone and offers managed certificates, while the customer still enforces HTTPS and TLS on its own endpoints and on partner exchanges. The effort shifts to confirming the boundary. You need the provider's documented responsibilities, a shared responsibility matrix that matches your architecture, and evidence that the provider's controls are current. Any endpoint you expose, certificate you issue or partner link you build stays in your scope. Read the inheritance guidance in the blog post for the exact example before you assume any portion is inherited.

What does a partner do for transmission protection, and what does the assessor do?

A partner plans and implements the work: it inventories endpoints and exchanges, hardens TLS configurations, sets up certificate automation, documents the controls and assembles the evidence. Under the structure HITRUST uses, the organization owns its controls and decides what goes into scope. The assessor is a different party. Only an Authorized HITRUST External Assessor may perform the validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing reports. Neither the partner nor the organization's own staff can issue the report or certificate. Any proposal that promises a result from HITRUST should be treated with caution, and the written scope should state which deliverables are preparation and which belong to the assessor.

Which cost components should I expect for transmission protection work?

Costs fall into a few groups. The first is the one-time preparation work: endpoint and exchange inventory, configuration changes, certificate architecture and evidence design. The second is recurring operation: certificate renewal, scan review, partner onboarding and periodic reviews of protocol settings. The third is the assessor's fee, which is paid to the External Assessor and not to the partner. Costs rise with the number of endpoints, the number of legacy clients, the number of third-party exchanges and the number of certificate authorities. They fall when certificate issuance is already automated and when a standard configuration covers most services. Ask any quote to separate these groups, state which items are one-time and which recur, and list the assumptions about endpoint count and legacy clients. DeployOpen prices from a written scope, so a quote will reflect the agreed boundaries.

Which open-source tools can support transmission protection evidence?

Several self-hosted open-source components can produce parts of the evidence, but each covers only part of the domain. cert-manager (Apache-2.0) creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or self-signed, stores them in Kubernetes Secrets and renews them before they expire. FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. OpenBao (MPL-2.0) offers a transit secrets engine that encrypts and decrypts application data without storing it and supports key rotation. Confirm that each tool's configuration, logs and certificate inventory meet what your assessor will sample, since the tool alone does not satisfy a requirement. Start with the HITRUST framework page to understand how the CSF is organized before selecting tools.

How self-hosted open source supports the evidence

Self-hosted open-source tools can produce much of the evidence an assessor asks for under 09 Transmission Protection, but they support the control rather than replace it. The organization still owns the decisions on which endpoints must use TLS, which certificate authorities it trusts and who approves exceptions. cert-manager (Apache-2.0) is the strongest fit for Kubernetes or OpenShift workloads: it requests certificates from an issuer such as ACME, a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer, stores them in Kubernetes Secrets and renews them before they expire. An assessor will typically want to see the issuer configuration, the certificate inventory and renewal events, so confirm which issuer your environment uses and where those records are kept.

For internal services that sit outside a cluster, FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag that can issue and manage certificates for hosts and services. Its value for this domain is a single, documented source of internal certificates with a traceable issuance history. Before relying on it, confirm with your architects which trust chains your partner exchanges expect, because an internal CA is rarely accepted by an external party without an agreed trust process. OpenBao (MPL-2.0) addresses a different gap: its transit secrets engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with key rotation. That helps where payloads must be protected at the application layer, but it does not terminate TLS, so it should be presented as complementary evidence.

Nextcloud's server-side encryption is an at-rest control. According to its admin documentation, it protects file contents on local and external storage with keys kept on the server, but it does not encrypt file names or folder structure. It therefore cannot be cited as transit evidence for file sync traffic, and HTTPS settings on the Nextcloud endpoint must be shown separately. Before the assessment window opens, ask your assessor which evidence they will accept for each in-scope transfer path, and map each tool to the specific endpoint or exchange it covers. Tools that cannot show that mapping will leave gaps regardless of how well they are configured.

How DeployOpen prepares transmission protection evidence

DeployOpen plans, implements and documents the encryption-in-transit controls behind the 09 Transmission Protection domain inside your own infrastructure. We prepare the systems and evidence an assessor will sample, while your organization keeps ownership of its controls and the independent assessor issues any report.

How we scope

Agree in writing which application endpoints, internal service paths and partner exchanges fall inside the 09 Transmission Protection scope.
Map which TLS termination points belong to your organization and which sit with a cloud or hosting provider.
Record certificate authorities, certificate lifecycles and partner connection methods so the boundary is clear before work starts.

How we build

Deploy and harden open-source components for certificate issuance, renewal and secrets handling inside your accounts or data centers.
Configure HTTPS and TLS settings on in-scope endpoints, with protocol and cipher policies documented and checked against your baseline.
Set up automated certificate renewal and key rotation so that expiry and key-handling events leave a traceable record.

How we hand over

Deliver configuration records, certificate inventories and renewal logs that show how each in-scope transmission path is protected.
Document the responsibility split with your cloud and third-party providers so inherited and customer-owned controls are distinct.
Provide a sampling-ready evidence index so your internal team or independent assessor can trace each control to its source.

How we support

Support ongoing operation, upgrades and periodic checks of TLS configuration and certificate health as a retainer after handover.
Review the domain again when the CSF version changes or when new endpoints, partners or AI services enter scope.
Confirm with your assessor which evidence format and retention period they expect before the fieldwork window opens.