Terraform vs OpenTofu: when each option fits your team
A renewal, a license review or a data residency rule is often what forces the choice of infrastructure as code CLI. Terraform fits teams that accept the terms of the Business Source License that applies to Terraform since version 1.6.0, and that want HashiCorp's roadmap, vendor support and the tight integration with HCP Terraform or Terraform Enterprise. OpenTofu fits teams that want a CLI under the Mozilla Public License 2.0 with stewardship by the Linux Foundation, and that are willing to track where the two projects diverge over time. The CLI is only one part of the decision, because the run and state layer you pick alongside it, whether that is Terrakube or Atlantis, has to work with whichever binary you choose.
Both tools read the same HCL configurations for most workloads, and OpenTofu describes itself as a drop-in replacement that preserves existing workflows. That compatibility is not a guarantee for future releases, though. OpenTofu's own FAQ states that feature parity with Terraform is an aim, and that the community decides which features it adopts. Features added after the fork, such as early evaluation of variables and locals, provider for_each and the -exclude flag, mean that a configuration written for OpenTofu may not run unchanged on Terraform. Confirm which OpenTofu release your team would pin and whether your CI images and provider versions were tested against it.
The decision turns on three checks. First, have legal counsel read the BSL against how your company uses Terraform, including internal production use, embedding and any paid support arrangements. Second, inventory your providers and modules, and confirm they are published in the OpenTofu Registry or can be mirrored, since the registry lists more than 3,900 providers and 23,600 modules. Third, list the features your code already depends on, such as state encryption, terraform_remote_state consumers or specific provider behavior, and test each one on the CLI you are considering before the contract date.
Which option fits which scenario
This table matches common situations to the option that usually fits better, with the condition that makes each advantage matter. Read the Why column first, since the right choice depends on your own pipelines, license position and configuration. Confirm any license question with your legal counsel before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Internal platform team running Terraform in its own pipelines | OpenTofu | Your pipelines call the CLI directly and do not sell IaC to others, so the license question is mostly about internal use. OpenTofu under MPL 2.0 removes that question, and the workflow stays the same because it is designed as a drop-in replacement. Confirm the internal use position with counsel if you stay on Terraform. |
| Company embedding IaC tooling in a product or service | OpenTofu, after legal review | If customers receive a product or hosted service that runs Terraform on their behalf, the Business Source License restricts certain competitive offerings. Ask counsel to read the license against your exact offering before you decide, and do not assume either option is free of obligations. |
| Team that needs state encryption from the CLI | OpenTofu | OpenTofu encrypts state and plan files on the client with key providers such as AWS KMS, GCP KMS and OpenBao. This matters when state holds secrets and you cannot rely on the backend alone. Check that your backend and tooling read the encrypted state as expected before you enable it. |
| Team with heavy terraform_remote_state dependencies | Terraform, or a staged OpenTofu move | Configurations that share outputs through terraform_remote_state need extra care during migration, and OpenTofu's guidance says so. If many stacks depend on each other, plan the move stack by stack and verify each one with a no-change plan before moving the next. |
| Team that wants minimal change to existing configurations | OpenTofu | OpenTofu describes itself as a drop-in replacement that preserves existing workflows and configurations, so the change is mostly the binary and the CI step. Confirm that your specific providers and versions behave the same in a test run, since future feature compatibility is not guaranteed. |
| Team that needs a vendor support contract | Terraform through HashiCorp or IBM, or a commercial OpenTofu support vendor | OpenTofu is community-governed under the Linux Foundation and has no single vendor contract by default. If procurement requires a named support obligation, ask the vendor in writing what is covered, the response terms and the escalation path. Confirm the license terms with counsel as well. |
| Team that wants a neutral foundation for long-term governance | OpenTofu | OpenTofu is under Linux Foundation stewardship and was accepted to the CNCF Sandbox on April 23, 2025, so decisions are made in a public project. Review the project's governance documents yourself to understand how features are chosen. |
How the BSL and MPL 2.0 change what you may do
Terraform and OpenTofu differ mainly in license, ownership and governance, and those differences shape what internal teams can run, modify and support. The four cards below cover the events behind the split and the questions to put to legal and procurement before any decision.
License change to the BSL
On August 10, 2023, HashiCorp announced that future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1. The main restriction targets vendors offering competitive services, so internal use of Terraform is the case most teams need to read closely. Ask legal to confirm how the BSL applies to your internal production use, your internal platform team and any embedded or customer-facing use. Use the BSL licensing page as the starting point for the detailed reading.
OpenTofu under MPL 2.0
OpenTofu is licensed under the Mozilla Public License 2.0, a file-level copyleft license that is generally regarded as permissive for internal use. For an internal user, this means you can run, modify and redistribute OpenTofu under MPL terms without a competitive-offering restriction. Ask legal to confirm the obligations that apply if you modify OpenTofu source files or ship a modified build to third parties, and record the version of the license text your team adopts.
Linux Foundation stewardship and CNCF Sandbox
The OpenTofu website states that the project is under the Linux Foundation's stewardship, and OpenTofu was accepted to the CNCF at the Sandbox maturity level on April 23, 2025. Stewardship by a neutral foundation changes who decides the roadmap and how contributions are governed, but Sandbox is an early maturity level. Ask procurement whether your standards require a project at a given CNCF maturity level, and confirm how your support provider will handle releases and security issues.
IBM ownership of HashiCorp
IBM completed its acquisition of HashiCorp, the maker of Terraform, on February 27, 2025. Ownership by a large vendor can change commercial terms, support packaging and product direction, which is one reason teams with long planning horizons review their options. Ask your account team in writing whether any Terraform license, support or subscription terms are changing under IBM, and ask legal whether your current agreement carries over.
How do Terraform and OpenTofu compare on capabilities?
This table compares the licence, governance, compatibility and key features of the commercial Terraform CLI and the open-source OpenTofu CLI, plus the run and state layer each depends on. Rows marked (verify) change over time, so confirm current behavior in the vendor or project documentation before you commit to a migration plan. The main takeaway is that OpenTofu's post-fork features are documented with release versions, while Terraform's equivalents need checking against your own version.
| Capability | Terraform (commercial CLI) | OpenTofu (open-source CLI) |
|---|---|---|
| License (verify current terms) | Business Source License 1.1 since Terraform 1.6.0 | Mozilla Public License 2.0 |
| Governance | HashiCorp, now owned by IBM after the acquisition completed February 27, 2025 | Linux Foundation stewardship; CNCF Sandbox project since April 23, 2025 |
| Configuration language compatibility (verify) | HCL configurations, with behavior set by HashiCorp's releases | Positioned as a drop-in replacement; confirm parity for each release |
| Provider and module ecosystem (verify) | Terraform Registry providers and modules; check each listing's terms | Same provider model; confirm each provider's support for OpenTofu |
| State encryption | Confirm current built-in options in HashiCorp's documentation | Client-side encryption with PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault, introduced in v1.7 |
| Early evaluation of variables and locals (verify) | Confirm availability in your Terraform version | Added in v1.8 |
| Provider for_each and -exclude flag (verify) | Confirm availability in your Terraform version | Added in v1.9 |
| Registry size | Check current published counts on the Terraform Registry | More than 3,900 providers and 23,600 modules, searchable on the OpenTofu registry search site |
| Run and state layer (verify) | HCP Terraform (billed per managed resource) or self-managed Terraform Enterprise | Terrakube or Atlantis, both Apache 2.0, hosted in your own infrastructure |
How far can OpenTofu and Terraform diverge over time?
OpenTofu states an aim of maintaining feature parity with Terraform for future releases, but its community decides which features it adopts. The project's FAQ is explicit that compatibility with future Terraform releases is not guaranteed. Today's shared core of language and workflow means most configurations run on both CLIs, but that shared core is a snapshot, not a contract. Since the fork, OpenTofu has added its own features, including early evaluation of variables and locals in v1.8 and provider for_each and the -exclude flag in v1.9. Terraform has also moved on under the Business Source License, so each CLI now has behavior the other may not share.
The practical risk is drift in both directions. A configuration that adopts a feature unique to one CLI becomes harder to run on the other, and the failure may only appear when someone runs the other binary in a pipeline or on a laptop. Provider and module authors may also target one CLI first, publishing releases that depend on new language behavior. Teams running a mixed estate, or planning to move back to Terraform later, should treat CLI choice as a version pin that needs the same discipline as a provider pin. Record which CLI and version each root module uses, and decide whether a module may use CLI-specific features before anyone writes them.
Before adopting any Terraform release or a new OpenTofu feature, run a short checklist against a copy of the configuration. Confirm the provider versions in the lock file resolve and plan cleanly on the target CLI. Test every custom function and any module that relies on language behavior introduced after the fork. Check each Terraform release you plan to adopt against the OpenTofu release notes before upgrading, and keep a no-change plan as the acceptance test. The OpenTofu website lists current features, and the project's release history on GitHub shows what has shipped, so review both on the day you set your target version.
Which features came after the fork, and when they matter
Terraform state and plan files can contain secrets in plain text, including database passwords and generated keys. OpenTofu encrypts both at rest, in local storage and in remote backends. This matters most when state sits in a shared backend, when plan files pass between pipeline stages, or when auditors ask how secrets are protected in state. The supported key providers include PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault, and the feature was introduced in v1.7 according to the OpenTofu state and plan encryption documentation.
- Key custody: A passphrase-derived key (PBKDF2) is simple to start with, while KMS or OpenBao keys move custody to a service your security team already operates.
- Tools that read state: Scripts, dashboards and other configurations that read state directly must be able to decrypt it, so inventory those readers first.
- Key rotation: Plan how keys are rotated and how existing state is re-encrypted, and test that a restore works with the key you keep.
- Plan files in CI: Confirm that saved plan files are encrypted and that artifact retention policies match your data handling rules.
In a non-production workspace, confirm that a state read, a plan and an apply all succeed after encryption is enabled, and record which key provider and key owner each environment uses.
OpenTofu v1.8 added early evaluation of variables and locals, which lets certain values resolve before the main plan runs. Configurations can then use variables and locals in places the Terraform language usually treats as static. This matters for teams that want to set module sources, versions or similar inputs from one place, so they do not maintain near-identical blocks for each environment. Because this is an OpenTofu addition made after the fork, a configuration that depends on it may not run under Terraform.
- Qualifying fields: Confirm in the OpenTofu documentation for your exact release which block arguments accept early-evaluated values.
- Portability: Configurations that use early evaluation may fail under Terraform, so keep a Terraform fallback only while a team still needs one.
- Environment consolidation: Teams with many environment folders that differ only in inputs gain the most from consolidating those inputs.
- Pinned versions: Pin the OpenTofu version in CI and in developer tooling so every run evaluates expressions the same way.
Run a plan for each environment with the pinned version and compare the output with your current Terraform plan before adopting early-evaluated expressions across the codebase.
OpenTofu v1.9 added for_each to provider blocks, so one provider definition can create several configured instances from a map or set. It also added the -exclude flag, which lets an operator run a plan or apply against everything except the addresses listed. Both matter when one configuration manages many regions, accounts or clusters, or when an operator must hold a resource out of a run without editing code. Teams without this feature typically repeat provider blocks by alias for each target.
- Multi-account layouts: A map of regions or accounts can drive provider instances, which reduces copy-paste across aliases.
- Targeted exclusion: -exclude can hold back a resource during an incident, but the skipped resource can still drift, so schedule a follow-up run.
- Runbook wording: Update runbooks so operators use the correct flag for each situation and understand what each one skips or selects.
- Pipeline policy: Decide whether exclusion is allowed in production pipelines or only in a documented break-glass procedure.
Test both features in a sandbox workspace that copies your provider layout, then confirm the plan output lists exactly the instances and addresses you expected.
The OpenTofu Registry lists more than 3,900 providers and 23,600 modules, and it is searchable from the OpenTofu website. Registry access matters when configurations pull providers and modules at init time, because a blocked registry, proxy or network rule can stop every run. It matters even more in air-gapped or egress-restricted networks, where teams must decide how providers reach their runners. A headline count does not show whether a specific provider your estate depends on is published, so check each one.
- Provider inventory: List every provider and version in your lock files and confirm each one resolves from the OpenTofu Registry.
- Module sources: Identify modules that point at other registries or Git sources and plan how each will resolve after the switch.
- Mirrors and proxies: Air-gapped or egress-restricted runners need a provider mirror or internal proxy, which is an operational component to budget and maintain.
- Lock file review: After the first init, review the lock file to see which provider sources and versions were recorded.
Run a clean init from a runner with the same network rules as production, and confirm every provider and module resolves before any plan is approved.
Where state, plans and runs live under each option
The CLI you choose does not decide where your data sits. HCP Terraform keeps state, plans and run logs in HashiCorp's hosted service, so moving the binary from Terraform to OpenTofu leaves that location unchanged until you move the workspaces. Terraform Enterprise is self-managed, but it is still HashiCorp software and its operational boundaries depend on how you deploy it. A self-hosted OpenTofu stack, with Terrakube or Atlantis running in your own accounts or data centers, keeps state and plan artifacts in storage you select. Confirm with each vendor exactly which artifacts (state, plan files, logs, variables and cached provider data) leave your environment, and where they are written during a run.
For an HCP Terraform exit, the state versions API is the export path. Each workspace exposes its current state, and for states created by Terraform 1.3 or later the API provides a JSON state download URL. Pull every workspace's state, store it in an encrypted location you control, and verify the serial and lineage against the live workspace before you cut over. Plan the cutover around a freeze on applies, because a state written after export will not be in your copy. Where your backend supports it, OpenTofu's state encryption can protect state at rest in remote backends using keys from AWS KMS, GCP KMS, OpenBao or Azure, so the key material and the ciphertext are controlled separately. Test that every tool reading state can still decrypt it before you rely on the setting.
Several controls move to you regardless of the option you pick. Identity for operators and pipelines, role-based access to workspaces and state buckets, audit logging of plans and applies, and retention of those logs are items you must design and evidence yourself. A hosted service may supply some of these as features, but you should confirm what it records and for how long. DeployOpen can help plan and configure these controls and prepare the evidence an assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What each option costs and what drives the bill
The bill for an infrastructure as code platform comes from four separate layers: the CLI, the run and state platform, the people who operate it, and the one-time work to move. Confirm each layer in writing, because a low license cost for the CLI says little about what the platform around it will cost to run.
CLI license cost
OpenTofu is licensed under the Mozilla Public License 2.0, and Terraform 1.6.0 and later are under the Business Source License. Both CLIs are typically downloaded and run without a per-seat fee, but the BSL terms decide what your company may do with Terraform, so legal review is a real cost line. Ask counsel to confirm the license terms for your specific use, including any commercial offering you build on top of the CLI. Keep the CLI version pinned in your repositories so upgrades are a scheduled decision.
Commercial run platform fees
HCP Terraform bills paid tiers per managed resource, with Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per resource per month, according to the HashiCorp pricing page. Terraform Enterprise, the self-managed edition, is priced on a custom basis. The recurring bill grows with the number of managed resources, so a large estate with many short-lived resources scales the cost faster than the number of teams. Ask any vendor for a quote based on your resource count today and at projected growth, and confirm which features sit in each tier.
Self-hosted run platform operations
Terrakube and Atlantis are both licensed under Apache 2.0, so the software itself carries no license fee. The recurring cost is the infrastructure that runs the platform, the database and storage behind state, backups, upgrades, access control and on-call support for failed runs. Those costs are paid to your cloud provider and to the engineers who own the platform. Ask for a written split between one-time setup and ongoing operations, and confirm who patches the platform and who responds when a run fails at night.
One-time migration and integration work
Moving off HCP Terraform is mostly a one-time cost: exporting state through the state versions API, re-initializing against the same backend, verifying with a no-change plan, updating CI pipelines and handling terraform_remote_state dependencies. Costs rise with the number of workspaces, the depth of cross-stack dependencies, and the number of pipelines that call Terraform directly. Ask for a fixed scope listing workspaces in scope, the migration method, verification steps, rollback plan and the handover documentation. Ask whether state encryption will be enabled during the move, since that adds key management work.
What a move from Terraform to OpenTofu involves
The sequence keeps your configurations and state where they are and changes the CLI that reads them, so each stage ends with a check that proves the move is complete. OpenTofu's migration guide describes the process as designed to be safe and reversible, and this sequence expands its four high-level steps for teams that also run HCP Terraform.
Inventory configurations, providers and state consumers
The platform or infrastructure team lists every root module, workspace and backend, the Terraform version each one last ran with, and the providers they pin in their lock files. Include any other system that reads state, such as pipelines, scripts or other stacks using the terraform_remote_state data source. The output is a written inventory with one owner per workspace, which becomes the checklist for every later step.
Back up state and code before any change
Before touching the CLI, the owner of each workspace takes a copy of its current state file, pulls the latest commit of the configuration, and stores both in a location outside the migration path. For HCP Terraform workspaces, this means downloading the state. Confirm that each backup can be read by the Terraform version you are running today. The migration is only reversible if these copies exist and open cleanly.
Install OpenTofu and initialize against the same backend
Install the
tofubinary on a workstation or runner, then runtofu initin a copy of one workspace, pointing at the same remote backend and state location as before. Expect OpenTofu to read existing state and lock files without rewriting the backend configuration. Record the OpenTofu version used, because later releases may diverge from Terraform. The step is complete when initialization succeeds without errors for that workspace.Verify the move with a no-change plan
Run
tofu planagainst each initialized workspace and confirm that it reports no changes to resources. A no-change plan shows that OpenTofu reads the same state, the same providers and the same configuration as Terraform did. If the plan proposes changes, stop, compare the provider versions and the configuration with the backup, and resolve the difference before moving on. Store the clean plan output as evidence for the change record.Handle terraform_remote_state dependencies with extra care
Stacks that read another workspace's outputs through terraform_remote_state need separate attention because the producer and consumer may move to OpenTofu at different times. OpenTofu's migration guide flags this case and links a dedicated guide. Agree a cutover order, confirm that each output is still exposed under the same name, and run a no-change plan on every consumer after its producer moves. The step is complete when each dependency has been tested in both directions.
Move run and state management to the new platform
If you are leaving HCP Terraform or Terraform Enterprise, the state for each workspace moves out through the state versions API, which exposes a JSON state download URL for states created by Terraform 1.3 or later. Import that state into the backend your run platform uses, such as Terrakube or Atlantis, and check that the workspace's variables, variable sets and access rules have been recreated. Confirm the imported state with a no-change plan before any pipeline runs against it.
Change CI and run tooling to call OpenTofu
Update pipeline definitions, pull request automation and wrapper scripts so they call
tofuinstead ofterraform, pin the OpenTofu version, and reference the same state and lock locations. Confirm that the pipeline produces the same plan output as the manual check from earlier. The migration is finished when every workspace in the inventory has passed its no-change plan through the automated pipeline, and the old Terraform binary is no longer used for any workspace.
Questions buyers ask before choosing between Terraform and OpenTofu
How much effort does switching from Terraform to OpenTofu take?
The effort is usually modest for a small estate and grows with the number of root modules, state backends, CI pipelines and cross-stack dependencies. OpenTofu's migration guide describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, and test with a small change, which the project describes as designed to be safe and reversible. The main drivers are how many workspaces or stacks you run, whether pipelines call the terraform binary by name, whether you use the terraform_remote_state data source, and whether your state currently lives in HCP Terraform. Start by inventorying those items. You should also confirm that your providers are available in the OpenTofu Registry, which the OpenTofu website lists as containing more than 3,900 providers and 23,600 modules.
Can our own platform team migrate to OpenTofu without outside help?
Many teams can migrate in-house when the estate is small, the configurations are mostly standard, and one person owns state backups and verification. The documented steps are sequential and reversible, so a pilot workspace is a sensible first move. Work gets harder when state is pulled from HCP Terraform, when remote state dependencies cross team boundaries, or when pipelines need redesign for new binaries and container images. Before deciding, run a no-change plan in a non-production workspace after migration, and confirm with your own change process how rollback will work. If several of these conditions apply at once, a written scope with an external partner can be easier to govern than an open-ended internal project.
How long does a Terraform to OpenTofu migration take?
No fixed duration applies to every environment, so ask for an estimate based on your own inventory rather than a generic number. The main drivers are the count of workspaces and stacks, the number of pipelines and the owners who must approve changes, the number of cross-team state dependencies, and how many environments must be verified before production. Change freeze windows and audit evidence requirements also affect the calendar, even when the technical steps are short. Ask any vendor or partner to list the phases, the entry and exit criteria for each phase, and which parts depend on your teams' availability. The migration overview on the OpenTofu site is a good baseline for building that list.
What does a migration need from our internal staff?
A migration needs a small set of named owners rather than a large team. Expect to involve:
- Platform or cloud administrators who approve state access, backups and any changes to backend permissions.
- Pipeline owners who update CI jobs, runner images and credentials to call OpenTofu.
- Module and application owners who review plan output and confirm that no unexpected resource changes appear.
- Security staff who decide whether state encryption keys will come from AWS KMS, GCP KMS, OpenBao or another supported provider.
- A change approver who signs off on the cutover and the rollback path.
Agree these roles and their time commitments before the work starts, because delays usually come from approvals rather than from the CLI itself.
Will OpenTofu stay compatible with future Terraform releases?
Compatibility with future Terraform releases is not guaranteed. The OpenTofu FAQ states an aim of maintaining feature parity with Terraform, while the community decides which features OpenTofu adopts. Divergence has already started: OpenTofu's site lists early evaluation of variables and locals in v1.8, and provider for_each along with the -exclude flag in v1.9. Configurations that depend on those features may not run unchanged on Terraform. Confirm your position by reading each OpenTofu release note against the Terraform changelog, pinning versions in your pipelines, and testing upgrades in a non-production environment before you adopt a new release. Licensing terms for Terraform are a separate question, covered by the license page in this group.
Does OpenTofu state encryption require rewriting our configurations?
Encryption changes how state and plan files are stored, so it needs a deliberate rollout, but it does not automatically mean a full rewrite of your infrastructure code. OpenTofu encrypts state and plan files at rest, for local storage and remote backends, using key providers that include PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault. The rollout work usually concentrates on the encryption settings, key access policies, key rotation procedures and any tools that read state directly. Confirm in the OpenTofu encryption documentation exactly which settings your versions require, and test that every tool reading state can still do so before enabling encryption on production state.
Should we hire a consultant to move from Terraform to OpenTofu?
Hire a consultant when the scope is larger than your team can absorb without slowing delivery, or when you need independent verification of the cutover. DeployOpen plans, implements, integrates, backs up and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. Cost depends on the number of workspaces, pipelines, dependencies and environments, and on how much verification and documentation you require. Ask any provider for a written scope that lists these items, the exit criteria for each deliverable and what your staff must supply.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Terraform vs OpenTofu, we start with a written view of which Terraform features your configurations actually use, then help you decide whether to stay on Terraform or move to OpenTofu.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which configurations, backends, providers and CI pipelines are included in the Terraform or OpenTofu review.
- We identify terraform_remote_state dependencies and features added after the fork, such as state encryption, before any version decision is made.
How we build
- We set up a test environment in your infrastructure and run a no-change plan against copies of your existing state.
- We document the migration steps, rollback points and any configuration changes needed for OpenTofu compatibility.
- We integrate the chosen CLI with your run and state platform, whether Terrakube or Atlantis, and test it with a small change.
How we hand over
- You receive runbooks covering installation, backend configuration, state handling and the steps for a safe, reversible rollback.
- Deliverables include a record of which provider and module versions were verified and which items remain open for your team to confirm.
- We walk your platform and security teams through the setup so they can operate and review it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover tracking new OpenTofu releases and checking your configurations for compatibility before you upgrade.
- DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
