Insomnia alternative for air-gapped and local-only teams

Why an air-gapped team needs an API client that never calls a vendor cloud

An air-gapped team should use an API client that never sends requests, collections or credentials to a vendor cloud. For single-user or file-based work, that means offline Bruno. For shared workspaces, it means a self-hosted Hoppscotch instance inside the isolated network. Insomnia's Scratch Pad and Local Vault support local work without a Kong account, but features that sync collections through Kong's infrastructure, such as Cloud Sync and Git Sync, depend on Kong's cloud and an account. Many teams use those features without trouble, so the real test is whether your network policy permits any vendor cloud path for API traffic or collection data at all.

The deciding question is whether your team needs shared workspaces. Bruno stores each collection as files in a local folder, and its README states that the app is offline-only with no plans for cloud sync, so teams share work through Git or another version control system they host. Hoppscotch Community Edition keeps team workspaces in a PostgreSQL database set through DATABASE_URL and runs as Docker containers on your own servers. Its sign-in options include Email, GitHub, Google and Microsoft OAuth, so confirm which providers your network can reach, because an external OAuth provider breaks the air-gap for logins.

Before you choose, confirm three things with your security team: whether the client may make any outbound connection, who installs, patches and backs up the Hoppscotch containers and database, and how installers and updates cross the isolation boundary. Bruno ships as a desktop binary for macOS, Windows and Linux, so an approved internal copy may be enough for a small group. The Hoppscotch install and build guide shows what the self-hosted path requires. If your sector follows NERC CIP-013-2, verify software integrity and authenticity for every package you carry across the boundary.

What an isolated network requires from an API client

An API client on an isolated network has to keep requests, collections and credentials inside the boundary and arrive there by a path the team can verify. The cards below cover the requirements that connect those goals, from outbound traffic to how packages cross the boundary. Each one is a check to run against Insomnia, Bruno or a self-hosted Hoppscotch before a rollout.

No outbound calls for collections

Confirm that the client sends API requests only to the hosts your collections name, and that it does not sync collections, environments or history to a vendor service in the background. Insomnia's Scratch Pad and Local Vault need to be tested with network monitoring turned on, because most of its sync and account features depend on Kong's cloud. Bruno's README states that it is offline-only and has no plans for cloud sync, so the check is mainly to confirm your build and plugins do not add outbound traffic.

Collections stored where you control them

Decide where collection files live before anyone builds one. Bruno keeps collections as files in a local folder, which you can place on an encrypted share and version in an internal Git server. Hoppscotch Community Edition keeps team workspaces in a PostgreSQL database that you host and back up. Either way, the team owns the storage location, retention and access controls, and the client should never be the only copy.

Credentials kept out of shared files

Collections often contain bearer tokens, API keys and basic auth passwords. Check how each client stores them, whether environment secrets can be kept out of exported files, and whether the team can reference a vault or local variable instead of a literal value. Review any export before it leaves the enclave, because a single shared file can carry the same secret into an unintended location.

Offline installation and updates

Plan the install from a staged package set, not from a package manager that reaches the internet. Bruno ships as desktop binaries for macOS, Windows and Linux, so you can stage the installer and its dependencies. A self-hosted Hoppscotch instance needs its container images, build inputs and Node.js dependencies available inside the network, and each upgrade repeats that work. Ask your vendor or integrator which artifacts are needed for an offline install and how updates arrive.

Verified packages across the boundary

Every installer, container image, plugin and collection file that crosses into the isolated network should be checked for source, hash and signature before import. NERC CIP-013-2 addresses this in the utility sector: it expects procurement processes to cover verifying that vendor software and patches are genuine and intact. Record who approved each transfer and keep the transfer log with the change records, so the same checks can be shown at an audit.

Import without outside services

Migration tools often reach out to a vendor converter or cloud service. Test Postman and Insomnia imports, and OpenAPI imports, with the network blocked. Bruno's Postman import and Hoppscotch's importer both run in the client or server you host, but confirm that each conversion completes offline and that scripts flagged as unsupported are reviewed by hand.

What Insomnia's local features cover without Kong's cloud

The first question for an air-gapped team is which Insomnia features still work without a Kong account and without reaching Kong's cloud. Scratch Pad and Local Vault are the two areas to test, because they are the parts of Insomnia that keep work on the device. Scratch Pad is the place for requests that are not tied to a synced project, and Local Vault is the storage option for environments and secrets on the local machine. Confirm with Kong, for your specific Insomnia version and edition, exactly what each one saves, where the data is kept, whether it is encrypted, and whether you can export it in full without signing in.

Most of the collaboration features sit behind an account. Cloud Sync, Git Sync, shared team projects, and the admin and single sign-on controls depend on Kong's services, and the paid tiers add more of them. Do not assume that a feature listed as local will stay local after an update or a plan change. Ask Kong in writing which features require a signed-in account, whether the app needs to contact Kong at startup or at intervals, and what happens to a licensed seat when the machine has no network access. Then verify on a machine with its network disabled: create a request, add an environment with a variable, add a script, save, close the app and reopen it.

The practical decision is whether Scratch Pad and Local Vault are enough for the work, or whether the team needs a model where collections move between people and build systems without a vendor account. If sharing and CI runs are required, the choice moves to a tool that stores collections as files the team controls, such as offline-only Bruno, or to a Hoppscotch instance hosted inside the isolated network. Either way, plan how collections and credentials cross the boundary, and keep a record of which version of the client each engineer runs, since local behavior can change between releases.

Which open-source API client fits each isolated-network pattern

This table compares Insomnia's local-only mode as the baseline with offline Bruno and a self-hosted Hoppscotch Community Edition inside an isolated network. Read each row against your own sharing, sign-in and CI needs, since the cheapest option on paper can carry the most upkeep. The main takeaway is that Bruno removes the server entirely, while Hoppscotch keeps shared workspaces but makes you run and patch it.

Requirement	Bruno (offline-only)	Self-hosted Hoppscotch Community
Insomnia local-only baseline	Closest match to Insomnia's local-only work: collections stay on the device with no account needed	Adds a server to run, so it is more than Insomnia's local-only mode
Where credentials live	Collections and any embedded secrets stay in a folder you choose on the device or file share	Data sits in your PostgreSQL database set through DATABASE_URL, inside your network
Team sharing	Shared through a Git repository you host inside the isolated network	Shared workspaces hosted on your server, with members managed by the administrator
Sign-in	No sign-in, because the app has no vendor account or cloud service	Email, GitHub, Google or Microsoft OAuth set by the administrator, plus SMTP for email
Automated runs in CI	bru run with test reports, run from your own build agents	hopp test from the CLI with JUnit XML output; the CLI is labeled alpha
Paid features to check	Git push, branch operations and merge conflict resolution in the app's Git UI need Pro or Ultimate	Enterprise Edition adds SAML SSO, SCIM and audit logs with a license key
Who runs the platform	Nobody beyond the desktop app and your Git server	Your team installs, upgrades and backs up the containers and database
Import from Postman or Insomnia	Imports Postman Collection v2 and v2.1 JSON; bulk import of a full data dump is in Ultimate	Imports Postman and Insomnia collections and environments, with a 50 MB self-hosted limit

Choosing Bruno or Hoppscotch by how your team shares work

When one analyst or a small group works on machines inside an isolated network and never needs a central service, Bruno fits the constraint most directly. Bruno is offline-only, and its README states there are no plans to add cloud sync. Collections are plain files in a folder on the filesystem, so nothing has to be hosted, patched or backed up as a service. The Open Source edition is the working choice for this pattern, and its pricing page marks the Git operations clone, initialize, diffs, pull and commit as included.

Storage stays local: Each .bru or OpenCollection YAML file lives on a disk you already control, so there is no database or account to approve.
Git works outside the app: Teams can version collections with any Git service already inside the enclave, using the normal review process.
Paid Git UI features are optional: Push, branch operations, remote connections and merge conflict resolution in the app are paid features, but Git itself still runs from the command line on any edition.
Packaging is manual: Install media for macOS, Windows or Linux must be checked and carried across the boundary like any other software.
Migration is file-based: A Postman v2 or v2.1 JSON export imports into Bruno, and the Open Source edition does not include bulk import of a full Postman data dump.

Before you rely on this model, confirm which Bruno release your change process will approve, since the Bruno GitHub releases page lists version 4.2.1 as current.

A small team that already runs an internal Git server can share collections as versioned folders without running any API client service. Each person clones the repository, works on a branch and commits changes, which gives you history and review. This pattern suits teams whose main need is consistency of requests and tests rather than live collaboration in a shared workspace. The cost is discipline: merge conflicts in files are resolved by people, and the Open Source edition does not provide a Git UI for pushing or resolving them.

Review through existing tools: Collection changes can go through the same merge requests or pull requests that govern application code.
Paid Git UI as a convenience: Bruno Pro and Ultimate add the in-app Git push, branch and conflict tools at a per-user rate listed on the pricing page, which is worth pricing against the time your team spends on Git by hand.
Secrets need a rule: Environment files and credentials must stay out of commits, so set a policy before the first push.
Format choice matters: Bruno 3.0.0 and later can save requests as OpenCollection YAML, which is easier to diff than the older plain-text format, though it is a change to agree on early.
CI can read the same files: The Bruno CLI runs bru run with test reports, so the repository can drive automated checks.

Confirm whether your Git server and CI runners sit inside the isolated network, and whether your change board accepts a paid per-user license if the team wants the Git UI.

When a team needs shared workspaces, member management and one place where collections and environments live, the answer moves to a self-hosted Hoppscotch instance inside the enclave. Hoppscotch Community Edition stores team workspaces in a PostgreSQL database set through DATABASE_URL, so the data and the administrators stay under your control. The operator installs, configures, upgrades and backs up the service, and the Community Edition documentation makes that responsibility explicit. Plan this as a small internal service with its own owner, not as a desktop tool.

Server footprint: The build step needs 4 CPU cores and 4 GB of RAM, and hosting the output needs as little as 1 CPU core and 2 GB of RAM, according to the prerequisites documentation.
Sign-in options: Community Edition supports Email, GitHub, Google and Microsoft OAuth providers and needs SMTP settings, so check that each provider is reachable and permitted inside your boundary.
Packaging: Docker images or a Helm chart for Kubernetes are documented, which suits enclaves that already run a container platform.
Migration path: The importer accepts Postman collections and environments, with a 50 MB limit on self-hosted editions.
Upgrades are yours: Community Edition releases are quarterly and supported through community forums, so the operator must schedule each upgrade.

Confirm your identity provider options against your sign-in policy before you install, since the Community Edition list does not include SAML.

How to deploy Bruno or Hoppscotch inside the enclave

This sequence moves API collections out of Insomnia and into a self-hosted client that runs entirely inside the isolated network. The result is an inventory, a chosen client, verified installers and images, imported collections, CI runs and documented upgrade and backup routines.

Inventory existing clients and collections
The API owner or platform lead lists every Insomnia workspace, project and collection in use, along with the environments, scripts and authentication settings each one depends on. Note which collections hold embedded credentials and which teams also use Postman, Thunder Client or OpenAPI files, because those affect the import path. The step is done when the team has one inventory document that names each collection, its owner, its storage location and its secret handling.
Choose Bruno or self-hosted Hoppscotch
Decide whether the team needs file-based, offline-only collections that live in Git (Bruno) or a shared server with team workspaces in PostgreSQL (Hoppscotch Community Edition). Bruno keeps collections as files on the user's filesystem and has no cloud sync, so it suits teams that version collections in an internal Git server. Hoppscotch suits teams that want shared workspaces, member management and sign-in on infrastructure they run. The step is done when a written decision records the choice and the reason, reviewed by security and the platform owner.
Stage installers and container images through a controlled transfer
The platform team downloads the chosen Bruno binary or Hoppscotch Community Edition container images on an external network, records their versions and checksums, and carries them across the boundary through the approved transfer process. Hoppscotch's Community Edition is packaged as Docker containers, so the team also mirrors the base images and any Helm chart it uses into an internal registry. Verify each artifact against the publisher's checksum or signature before import. The step is done when a transfer log lists every artifact, its hash and the reviewer who approved it.
Deploy Hoppscotch with PostgreSQL and internal sign-in
If Hoppscotch was chosen, the infrastructure team builds or deploys the containers on hosts that meet the prerequisites, which the Hoppscotch documentation lists as 4 CPU cores and 4 GB of RAM for the build image and as little as 1 CPU core and 2 GB of RAM to host the output. Point DATABASE_URL at a PostgreSQL instance inside the enclave, configure an internal identity provider or Email sign-in, and supply SMTP settings that resolve on the internal network. Confirm the OAuth providers the team plans to use, because GitHub, Google and Microsoft sign-in calls reach external services that an isolated network may not allow. The step is done when a test user signs in and a workspace saves to PostgreSQL.
Install Bruno and import collections
For Bruno, the endpoint team installs the desktop binary from the transferred package on each workstation, or points users to a shared internal distribution. Import Postman collections exported as Collection v2 or v2.1 JSON, or create collections from OpenAPI specifications using Bruno's import command. Review translated scripts and flag any Postman-specific packages such as postman-collection or newman, which Bruno reports as unsupported and must be rewritten. Commit the resulting collection folders to the internal Git server. The step is done when each migrated collection runs its requests against an internal test target and its environments resolve correctly.
Import collections into Hoppscotch and check limits
For Hoppscotch, import collections and environments from Postman or Insomnia exports, or collections from OpenAPI, through the importer. Self-hosted editions accept imports up to 50 MB, so split larger exports before upload. Recreate workspaces and members, then test a sample of requests against internal services. The step is done when imported collections match the inventory from the first step and no secret values remain in plain text in shared workspaces without an approved owner.
Wire the CLI into internal CI and set upgrade and backup routines
Connect collection tests to the internal CI system: run bru run with its test reports for Bruno, or hopp test with JUnit XML output for Hoppscotch. The Hoppscotch CLI is described as alpha and needs Node.js 22 or later, so pin its version and confirm the runtime exists in the enclave. Finally, document an upgrade routine that stages each new release through the same transfer process, and a backup routine that covers the PostgreSQL database and the Git repositories holding Bruno collections. The step is done when a CI pipeline publishes a test report, a restore from backup has been tested, and the upgrade and backup runbooks are approved.

How to move collections without leaking secrets across the boundary

Before any collection crosses into an isolated network, strip the secrets out of it. Postman collections, Insomnia exports and OpenAPI files often carry bearer tokens, API keys, basic-auth passwords and client secrets in headers, auth blocks, environment files and pre-request scripts. Export the collection, search it for credentials, move those values into the target tool's local environment or secret store, and confirm the file that crosses the boundary contains only placeholders. Bruno keeps environment values in separate files that you can exclude from what you carry over, so decide up front which files travel and which stay behind.

Bruno imports Postman Collection v2 and v2.1 JSON, and Hoppscotch imports Postman collections and environments and OpenAPI definitions. Bruno also translates common Postman script APIs such as pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response during import, while flagging Postman-specific packages such as postman-collection and newman as unsupported. Expect to rewrite any script that depends on those packages by hand. Bulk import of a full Postman data dump covering all collections and environments is a feature of Bruno Ultimate, so teams on the open-source edition should export collection by collection. For Hoppscotch, the importer accepts files up to 50 MB on self-hosted editions. Larger exports need to be split before import.

Test every import on a small set of sample collections before moving production data. Use a collection that exercises auth, environments, scripts and a few failing assertions, then confirm that requests, variables and test results match the source. Run the same sample through the CLI in the isolated network, using bru run or hopp test, so you know the runner works without internet access. Keep the sample and the import log as evidence for the change record. Confirm with the vendors that the import version you plan to use matches the behavior you tested, since converter coverage changes between releases.

Questions teams ask before moving an air-gapped API client

What does moving off Insomnia to an air-gapped client cost, and which parts are paid?

Expect costs in four buckets: client licenses, server hosting if you run Hoppscotch, implementation work, and ongoing support time. Bruno's Open Source edition costs $0, while its Pro edition is listed at $6 per user per month and Ultimate at $11 per user per month, both billed annually, according to Bruno's pricing page. Hoppscotch Community Edition is free to license, but you pay for the servers, the staff who run it, and upgrades. Licenses recur each year, while setup and migration work is largely one-time. Ask any implementation partner for a written quote that separates these buckets, states what is in scope, and lists which items recur.

How long does an air-gapped API client migration take, and what drives the timeline?

The timeline depends on how many collections, environments and scripts you have, how many people share them, and how your isolated network handles software transfer. Bruno collections are plain files in a folder, so a small team with a few collections can often move quickly. A self-hosted Hoppscotch instance adds build, deployment, sign-in and database setup, and it needs a clean build path inside the isolated network. Ask for a written schedule with milestones for the import, the review of scripts and authentication, and the cutover. Do not accept a duration that is not tied to a defined scope.

What does our team need to provide before the work starts?

Plan to supply the following before any work begins:

Staff who own the collections, environments and secrets, and who can approve the final set.
Access to the isolated environment, including a build host, container registry or package mirror, and a database for Hoppscotch.
A sign-in provider for Hoppscotch Community Edition, such as Email, GitHub, Google or Microsoft OAuth, configured by your administrator.
SMTP settings, because Hoppscotch Community Edition needs them for email.

Confirm each item with your own security and network teams, and record approvals in the written scope.

Can we do the migration ourselves with Bruno?

Yes, many teams can import and run Bruno themselves. Bruno imports Postman collections in Collection v2 or v2.1 JSON format and OpenAPI specifications, and it stores collections as files that you can keep in Git on your own systems. Its offline-only design means no vendor cloud is involved. Plan for manual review of scripts, because Bruno translates common Postman script APIs but flags packages such as postman-collection and newman as unsupported. Bulk import of a full Postman data dump is included in the Ultimate edition, so check that requirement before you start. A partner is useful when you need a documented migration, a review of scripts and authentication, or a repeatable process for several teams.

How do Bruno's paid seats compare with a self-run Hoppscotch Community server?

They solve different problems. Bruno's paid seats are per-user licenses for a desktop client that keeps collections in files, with no server to run. Hoppscotch Community Edition is free to license, but it is a shared server you install, administer and update, with PostgreSQL, sign-in and SMTP to maintain. Compare the seat price against the staff hours, hosting and upgrade effort the server needs, and ask for those figures in a quote. If your team only needs local, file-based collections, a Bruno Open Source install avoids server work entirely. If you need shared workspaces on your own network, weigh the server cost against the seats.

Does moving collections out of a vendor cloud remove all compliance work?

No. Moving collections to a local or self-hosted tool keeps requests and embedded credentials off a vendor cloud, which helps with data residency. It does not make your environment compliant by itself. You still need to control how software enters the isolated network, and you should verify that every package, image and update carried across the boundary is checked for integrity and authenticity. NERC CIP-013-2 describes this type of supply chain control for covered utilities. Ask your assessor which controls apply to your program, and ask DeployOpen for readiness support, understanding that independent auditors and certification bodies issue any audit report or certification.

What ongoing work does an air-gapped API client need after launch?

Plan for regular upgrades, backups and access reviews. For Bruno, that means updating the desktop binary, keeping collections in a versioned folder, and checking that scripts still run after upgrades. For self-hosted Hoppscotch Community Edition, the vendor describes quarterly releases that you install, administer and update, so you need a patch process, database backups and a support path through its community forum. Enterprise Edition adds priority support and guaranteed quarterly updates. Ask any partner whether ongoing support is a retainer and what it covers, and whether it includes upgrades and testing.

Evidence auditors and assessors ask for under this constraint

When API collections stay inside an isolated network, assessors want proof of where data goes, what came across the boundary and who can reach the tool. The cards below cover the records that show those controls working. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment outcome.

Approved client inventory

List every API client version allowed on endpoints inside the boundary, with the owner, the installation source and the approval date. Record whether each client is the offline-only Bruno desktop app or a browser session to a self-hosted Hoppscotch instance. Assessors will ask how an unapproved client would be detected, so note the software inventory tool that reports installed clients. Confirm that Insomnia cloud sign-in is disabled on any machine that still has it.

Data flow showing no vendor cloud calls

Document each path that request data, collections and credentials could take, and show that none leaves the boundary. For Bruno, that means collections are plain files in a local folder. For Hoppscotch, it means traffic only reaches the instance you host and its PostgreSQL database. Capture network evidence from a test run, such as firewall logs showing blocked outbound connections to vendor domains. Confirm with the vendor which features, if any, still phone home.

Integrity checks on transferred packages

Every installer, container image, npm package and Postman or OpenAPI file carried across the isolated boundary needs a recorded hash or signature check. Keep the transfer log, the checksum values and the person who approved each import. This is the control that NERC CIP-013-2 describes for verifying vendor software integrity and authenticity, and it is the evidence most often missing in air-gapped programs. Confirm your own transfer procedure before an assessor asks for it.

Configuration records for the self-hosted instance

For a self-hosted Hoppscotch Community Edition, keep the Docker or Helm configuration, the DATABASE_URL target, the OAuth provider settings and the SMTP settings under version control. Record the image tag deployed and the date each upgrade was applied. Assessors look for evidence that the configuration matches what was approved, so note any drift found during review. Bruno has less server configuration, but the approved folder structure and Git repository settings should still be documented.

Backup and restore records

Show that collections, environments and workspace data can be recovered. For Bruno, this means a tested copy of the collection folder, ideally held in the Git history that teams already use. For Hoppscotch, it means scheduled PostgreSQL backups and a restore test into a separate database. Record the last successful restore, who performed it and what was compared. Ask your backup vendor or operations team how restores are verified inside the isolated network.

Access reviews for sign-in

Hoppscotch Community Edition signs users in through Email, GitHub, Google or Microsoft OAuth providers that the administrator configures, so each sign-in method must be listed and reviewed. Keep the periodic review of active accounts, removals after role changes and the approval record for each identity provider. Bruno's Open Source edition has no account sign-in, so the evidence there is file access control on the shared folder or repository. Confirm which identity provider your isolated network can reach before the review cycle is set.

What offline tools will not cover

The main gap in an offline-first setup is collaboration. Bruno's README says collections are plain files in a folder, so teams share them through Git or another version control system, but the paid Git UI features are the ones most teams expect in daily use. In Bruno's pricing page, Git push, branch operations, remote connections and merge conflict resolution are paid features in the app's Git UI. The Open Source edition covers clone, initialize, diffs, pull and commit, and Git itself still works outside the app. Decide early whether your engineers will run push, branch and merge work from the command line, or whether you will budget for a paid Bruno edition. Confirm the current feature split on the pricing page before you commit to either path.

Hoppscotch Community Edition closes some gaps but not others. The Community Edition does not include SCIM provisioning or activity and audit logs, which the Enterprise Edition documentation lists as Enterprise features. If your controls depend on automated user lifecycle or an audit trail of who changed a shared collection, you will need to handle those with your own identity processes and database logging, or evaluate the Enterprise license. The Hoppscotch CLI, which runs hopp test for CI, is described as alpha in its documentation, so treat pipeline tests as a pilot before they become a release gate. Teams without a Hoppscotch server and without Git also need a written process for sharing collections, for example a controlled folder, a review step and a named owner for each collection.

Protocol coverage and feature availability change between releases, and both projects ship often. Bruno's current version is documented on its GitHub releases page, and Hoppscotch's on its own releases page. Before you approve either tool, install the version you plan to deploy in a test environment, import a representative collection, and check the protocols, authentication methods, scripting APIs and CLI behavior your teams use. Compare the results against the vendor documentation for that exact version. Record the result as part of your change file so that a later upgrade has a baseline to test against.

How DeployOpen works on this

DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an air-gapped API client rollout, that means agreeing in writing which client, which server and which package path the team will use before any work begins.

How we scope

Fixed-scope engagement: the written scope names the client, Bruno or Hoppscotch, and the isolated network it will run in.
The scope lists which collections, OpenAPI specs, environments and CI test runs must be migrated and in what format.
Retainers for ongoing support, upgrades and continuous testing are available and are defined separately from the initial scope.

How we build

Prepare the package path so installers, Docker images and npm packages for the CLI are checked and carried across the boundary.
For a self-hosted Hoppscotch instance, install the Community Edition containers, PostgreSQL database and sign-in settings inside the network.
Convert and test imported Postman or Insomnia collections, including scripts and authentication, before the team relies on them.

How we hand over

Documentation covers the build steps, the offline update procedure, and where collections and credentials are stored.
Evidence for supply chain controls, such as package verification records, is provided for your compliance team to review.
Handover includes a walkthrough of Git-based collection review for Bruno or user and workspace administration for Hoppscotch.

How we support

Support terms are set out in the written scope, including who applies vendor updates in the isolated network and how often.
Backups of the Hoppscotch database and collection repositories are configured and tested as part of the agreed scope.
Ask us to confirm which compliance evidence we prepare and which your independent auditor or certification body will need to assess.