Why document management in air-gapped networks is a different build
An air-gapped document archive is driven by three things before any feature list: how software and OCR language data get into the enclave, how documents get in without a network path, and how the archive proves its contents have not changed. For capture-led archives where scanned paper and inbound files are the main intake, Paperless-ngx is the usual starting point. For records-centric repositories with formal classification, retention and lifecycle rules, Alfresco Community Edition is the candidate to evaluate. In both cases, offline support is a per-product question to confirm in writing with the vendor, because air-gapped deployment is often reserved for paid editions. The Mattermost and Rocket.Chat plan pages show this pattern in adjacent tools, and the same gate may apply to document platforms.
Start by listing every artifact the enclave needs: container images with their digests, OCR language packs, base operating system packages, and any connectors for scanners or mail. Each one must be built or pulled on a connected staging network, verified, and carried across by an approved transfer path. This is the control a NERC CIP-013-2 style procurement process would expect, which asks for verification of software integrity and authenticity of vendor software and patches. Ask the vendor which release artifacts they publish for offline install, whether they sign them, and what the upgrade procedure looks like when a new image must cross the boundary. Kubernetes documents how to pre-pull control plane images and point a cluster at a private registry, which is a useful pattern to test against.
Intake and integrity come next. Scanners and import folders must sit inside the enclave, so decide where the import share lives, who can drop files into it, and how each file is logged on arrival. Plan for checksums at ingest, scheduled integrity checks on the stored originals and the search index, and backups that can be restored without any external service. Test a full restore inside the enclave before go-live. Because the same enclave often needs security monitoring, confirm that the logs from the document platform, the import share and the backup jobs can be collected by a locally hosted tool, such as Wazuh with its offline installation guide, rather than assumed.
Which requirements change when the archive has no internet path
This table compares the build requirements an air-gapped document archive must meet, from offline images and OCR packs to audit, transmission and package integrity controls. Read the last column to separate regulation-specific obligations from general hardening that applies to any disconnected system. The main takeaway is that most air-gap work is supply chain and evidence work, not installation work.
| Requirement | What it means for the build | Type |
|---|---|---|
| Offline container images and private registry | Every image, base layer and dependency is pulled on a connected staging network, verified, then loaded into an internal registry the archive pulls from. Confirm the image list and rebuild path with the vendor before you start. | General hardening |
| OCR language packs and models | OCR engines and each language pack must be carried in as files, with versions recorded. Missing packs fail silently on import, so test every language your records use before cutover. | General hardening |
| Scanner and import folder placement | Scanners and watched import folders sit inside the enclave, with defined file hand-off from the capture zone. Decide who may drop files, how they are scanned for malware, and how failed imports are reported. | General hardening |
| Audit controls (164.312(b)) | The HIPAA Security Rule requires audit controls that record and examine activity in systems holding ePHI. The archive must log access, edits and deletions locally, because external log services are unavailable, and someone must review the logs. | Regulation-specific (HIPAA) |
| Retention and preservation (17a-4) | For broker-dealer communications, SEC Rule 17a-4(b)(4) requires preserving originals for not less than three years. A general archive needs a compliant storage or retention arrangement that the examiner-facing evidence can support. | Regulation-specific (SEC) |
| Transmission security (164.312(e)(1)) | Document transfers into and out of the enclave, including sync between sites and backup copies, need encryption and protection against unauthorized access. Confirm how transfers across the boundary are protected. | Regulation-specific (HIPAA) |
| Software integrity for carried packages | Each package, image, rule set and patch crossing the boundary is checked for authenticity and integrity against vendor-provided hashes or signatures, with the check recorded. NERC CIP-013-2 is the reference control for verifying vendor software and patches. | Regulation-specific where NERC CIP applies, otherwise general hardening |
| Backup and integrity checks | Backups stay inside the enclave or on approved offline media. Scheduled restore tests and checksum verification of stored documents show the archive can be recovered without internet access. | General hardening |
| Update path across the gap | Updates are staged, tested in a non-production enclave, then carried across on approved media with a change record. Ask the partner for the documented sequence and rollback steps. | General hardening |
How offline images, OCR packs and updates change the build
The core build decision is that every artifact the cluster or application needs must be fetched before the enclave is sealed. For a Kubernetes control plane, the documented pattern is to run kubeadm config images list to see which images a given version requires, then kubeadm config images pull on a connected staging host, and finally point kubeadm init at an internal registry with --image-repository. The same logic applies to the rest of the stack. Container images for the document system, its database, cache and reverse proxy need to be pulled, saved and loaded into the enclave registry. Tesseract language data for OCR, which is often forgotten until the first scan fails, must be packaged as files and checked against the language packs your team has approved. Connector packages for scanners, mail gateways or identity sources follow the same rule. Confirm each platform's offline install steps with its vendor documentation before you commit to a version, because the list of required images and data files changes between releases.
The update path is where most air-gapped archives fail over time. Treat each update as a controlled transfer with four stages. First, the update is assembled on a connected staging host and written to approved media. Second, the media is scanned for malware and every file is hashed, with the hash manifest recorded outside the enclave so the enclave team can verify it independently. Third, the verified artifacts are imported into the internal registry and the platform's offline install or upgrade procedure is run. Fourth, the update is applied in a non-production zone of the enclave that mirrors the production configuration, with a restore test of a recent backup and a check that OCR output and permissions behave as before. Only after those checks does the change go to production. Ask your partner who approves each stage, how media is logged, and how a failed update is rolled back.
Run an update test as a decision point, not a formality. If an upgrade cannot be staged and tested in a non-production zone within your change window, the archive should not be patched until that gap is closed. For regulated owners, record the hash manifest and approval for each transfer, since it becomes supporting evidence for change management and supply chain reviews. Where operational technology is nearby, the NERC CIP-013-2 requirement on verifying software integrity and authenticity of vendor software and patches is a useful reference for the same discipline, even if your sector is not energy.
Which open-source document platforms fit an enclave, and why
An enclave shifts the question from which platform has the most features to which platform can be installed, updated and audited without reaching the internet. The options below pair a document repository with the monitoring, code and network tools around it, because each one needs its own offline install path and update route.
Paperless-ngx for scan-led capture
Paperless-ngx suits teams whose main intake is paper and scanned mail, with Tesseract OCR converting scans into searchable text inside the enclave. Before committing, confirm that every container image and dependency can be mirrored into the enclave registry, that the OCR language packs your records need are staged offline, and that scanner drivers and import folders work with no route out. Plan encryption at the storage layer, since the platform does not provide encryption at rest on its own.
Alfresco Community Edition for records
Alfresco Community Edition fits teams that need a content repository with versioning and filing rules, rather than a scanning pipeline as the main entry point. Its fit in an enclave depends on the support model, because patches and upgrades must arrive as bundles the team can verify. Confirm the license terms for your use, whether its retention features meet your schedule, which search and indexing components must run inside the enclave, and whether the vendor documents an offline install and upgrade path for the release you plan to run.
GitLab offline guidance for pipelines
Enclave teams often keep configuration, deployment code and workflow definitions in version control, so the pipelines that build them must run without internet access. GitLab documents self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners. Confirm which scanners, runner images and package registries your pipeline uses, which of them the offline guidance covers, and how each GitLab update will cross the boundary as a checked artifact.
Wazuh offline installation and vulnerability data
Wazuh provides host and endpoint monitoring for systems around the document archive, and its documentation covers an offline installation for systems without internet connectivity. Its vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, so someone must load and refresh that repository through the transfer process. Confirm which agent packages, rule sets and feed updates you will stage, and record how each import is verified before it reaches the manager.
Security Onion airgap updates
Security Onion supports full installs without internet access, and its ISO carries packages along with NIDS, YARA and Sigma rules. The soup tool updates an installation from newer ISO media in airgap mode, so updates arrive as media transfers that the team must verify. Confirm how each ISO is checked on entry, which rule sets the enclave needs, and how the network team will document sensor placement and the monitored segments before the design is approved.
Which enclave pattern fits your network: fully disconnected, diode or staged transfer
In a fully disconnected enclave, the document archive has no network path to any outside system. Every container image, OCR language pack, package and document crosses the boundary on approved removable media that a named custodian carries in and logs. Scanners and import folders sit inside the enclave, so paper is digitized and filed without ever leaving the protected network. The main risk is that the transfer process is manual, so the controls around it carry most of the weight.
- Data path: Media is prepared outside, scanned for malware, hashed, then imported through a documented procedure into a staging location inside the enclave before it reaches the archive.
- Media handling: A designated custodian signs each item in and out, and two-person handling is a common requirement to confirm with your security office.
- Scanner placement: Scanners, import folders and the OCR worker sit entirely inside the enclave, with no cloud print or vendor cloud services.
- Transfer logging: Each media event should produce a record of the item identifier, hash values, custodian, time and the import job, kept in a store that the archive cannot alter.
- Updates: Offline image bundles and OCR language packs arrive as signed, versioned sets, and the enclave team must confirm how integrity checks run before anything is deployed.
Confirm with your security office whether the enclave's accreditation allows removable media at all, and who approves each transfer.
A one-way data diode is a hardware device that lets data pass in one direction only. It suits an enclave that must receive documents from an outside source, such as a mail gateway or a supplier portal, while blocking any return path. Inbound files are captured on the external side, pushed across the diode and imported into the archive. Nothing from the enclave can reach the outside, which removes the risk of exfiltration through the link but makes error recovery harder.
- Data path: The external capture host writes files to a sending interface, the diode forwards them, and a receiving host inside the enclave places them in an import folder for ingestion.
- Media handling: Media is used less often, but it still matters for software updates, which cross the boundary by the same manual route as the fully disconnected pattern.
- Scanner placement: Scanners can sit on the external side for inbound paper, with output pushed through the diode, or inside the enclave if the paper itself must stay in the zone.
- Transfer logging: Logs are written on both sides and can be compared, but the receiving side cannot send acknowledgements back, so verification must rely on checksums carried inside each file.
- Failure handling: Dropped or corrupted transfers are not retransmitted automatically, so the design needs a sequence check and a reconciliation report on the outside.
Confirm the diode vendor's throughput limits, the protocol it supports and whether its logs satisfy your examiners or auditors.
In a classified or sensitive zone, documents from a less protected network go through a staged review before import. The review might check classification markings, remove metadata, confirm the sender and approve the item for the higher zone. This pattern is common where a separate authority owns the release decision, and it adds steps that must be recorded, not just performed. The archive should import only from the review stage, never directly from the source network.
- Data path: Items move from the source zone to a quarantine stage, then to a review stage where an authorized reviewer decides, and only approved items reach the import folder in the enclave.
- Media handling: Reviewers and transfer operators are separate roles, and any physical media is logged at each hand-off between stages.
- Scanner placement: Scanning often happens in the review stage or in a dedicated scanning room, so that paper enters the zone only after the review rules are applied.
- Transfer logging: Each stage writes its own record with reviewer identity, decision, reason and timestamp, and the archive stores the decision record alongside the document.
- Access separation: Administrators of the archive should not hold reviewer rights, and the review stage should not be able to edit archived records.
Confirm the review criteria, reviewer roles and retention period for stage logs with the zone's accreditation authority before you design the workflow.
How the enclave rollout runs from media inventory to first controlled update
The rollout sequence moves a document archive from an approved bill of materials into a tested enclave, then proves it can be backed up, restored and updated across the boundary without losing integrity. Each phase closes with a written output that the client's security and records owners can sign off.
Inventory requirements and approved media
The implementation team and the client's security, records and infrastructure owners agree on what the archive must hold, which OCR languages and scanner models are in scope, and which transfer media and approval path the enclave owner accepts. DeployOpen documents the classification of the enclave, the retention rules that apply and who may bring media across the boundary. The step closes with a signed requirements register and an approved list of transfer methods. Confirm early whether your accreditation or security plan restricts specific media types.
Build the offline bill of materials
Engineers list every artifact the enclave needs: container images and their digests, the Paperless-ngx or Alfresco release chosen, the database and Redis images, OCR language packs, scanner drivers, import connectors, reverse proxy and TLS components, and the licenses that cover each one. Where the platform depends on Kubernetes or Docker, the list also covers the base images and any orchestration packages. The step closes with a versioned bill of materials that the client approves before anything is downloaded. Ask the vendor or project which mirrors and registries they publish to, since that determines what can be pulled in the staging zone.
Stage and verify artifacts in a build zone
Outside the enclave, in a staging zone that has internet access, the team pulls the approved artifacts, mirrors them into a private registry and records checksums and signatures for each file. Images are scanned for known vulnerabilities and the results are kept with the bill of materials. The step closes with a transfer package and a manifest that lists every file, its hash and its scan result, so the enclave side can confirm the package is complete and unchanged. Where the platform has a documented offline install path, follow it exactly and record any deviation.
Install the archive inside the enclave
Once the transfer package passes hash checks on the enclave side, the team installs the archive from the private registry, loads the OCR packs, configures storage and connects the document consumption folder. Scanner intake is tested with known sample documents across the scanner models and file formats in scope, checking that files are picked up, OCR output is searchable, metadata and permissions apply as designed and audit events are written. The step closes with a test record showing pass or fail for each intake path, plus a list of open defects with owners.
Prove backup and restore before go-live
The team runs a backup of the document store, database and configuration, then restores it to a separate instance inside the enclave and compares document counts, checksums, permissions and search results against the source. Backup media and keys are stored and labeled under the client's handling rules. The step closes with a restore report that records the time and steps taken, any discrepancies and the decisions made about them. Records owners should confirm that the restored copy meets their retention and integrity requirements, not only that it starts.
Run the first controlled update across the boundary
The first update cycle repeats the full path: a new release is evaluated in the staging zone, its bill of materials and manifest are updated, the package is transferred under the approved process and installed on a test instance in the enclave before production. Changes to OCR packs, connectors or scanner drivers are included. The step closes with a change record that shows what was transferred, the verification results, the rollback plan and the approval for production. Ask the client's change board how long a transfer approval takes and what evidence it requires, since that sets the practical cadence for updates.
Hand over runbooks and evidence
DeployOpen hands over the architecture record, the bill of materials, the transfer and verification procedure, runbooks for scanner onboarding, backup and restore, user and permission administration, and the audit log review. Operators are trained on the procedures and the client's owners accept the handover in writing. The step closes with a signed handover pack and a list of recurring tasks, such as checking backup integrity and reviewing audit events. Confirm with the client's auditors which evidence they expect to see during their assessment.
Which integration points and controls sit inside the enclave
What internal container registry does an air-gapped document archive need?
An internal registry is the only place the archive's container images should be pulled from once the enclave is sealed. It protects you from pulling unreviewed images and makes every deployment reproducible from a known set of digests. Mirror the images, the base images and any OCR language packs into the registry during a staging step outside the enclave, then scan them before they cross. Confirm with the vendor which image tags, digests and helper images the release needs, whether the chart or compose files pin them, and whether any component still attempts an outbound pull on startup. Kubernetes can be built offline by pre-pulling control plane images and pointing the installer at a private registry, which shows the general pattern even if your archive runs on Docker Compose.
How do scanners and import folders feed documents into an enclave archive?
Intake is the point where paper and files enter the enclave, so it is where malware, mislabeled files and unsupervised uploads get in. Keep scanners on a segment that can reach only the intake share or the archive's consume folder, and use a dedicated service account with write access to that folder only. Define who may drop files, what file types are accepted, and how a failed import is quarantined and reported. Ask the vendor how the consume folder is watched, whether duplicates are detected, how OCR language packs are installed offline, and what the archive logs for each imported file.
How should identity and directory integration work inside the enclave?
Users inside the enclave should authenticate against a directory that also lives inside the enclave, such as an on-premises Active Directory or an LDAP service, so that no login depends on an external identity provider. This keeps access reviews, leaver removal and group-based permissions under your own control. Confirm with the vendor whether the archive supports LDAP or OIDC against a local provider, how group membership maps to document permissions, whether local fallback accounts exist and how they are protected, and whether session timeouts and MFA options work when the external network is absent. Test a disabled account to confirm access is actually removed.
What should the backup target hold when no network path exists?
The backup target must be physically or logically isolated from the production enclave and must produce offline copies that can be restored without a network link. Typical choices are an on-premises backup appliance on its own segment, or removable media rotated under a documented procedure. Cover the database, the document store, the search index and the configuration files, because a restore of only the files will not bring the archive back into a usable state. Ask the vendor which components must be backed up together, whether the OCR index can be rebuilt, how encryption keys are backed up separately, and how many generations you keep offline.
How do checksums and restore tests prove the archive is intact?
Checksums show that a stored file has not changed since it was recorded, and restore tests show that the backup can actually rebuild the archive. Both are needed because a checksum on a corrupted backup still matches itself. Record a hash manifest for every ingested document and for each backup set, store the manifests separately from the data, and verify them on a schedule. Run a full restore into a separate test enclave at a defined interval and compare document counts, hashes and a sample of searchable text. Ask the vendor which hash algorithm the archive uses, whether it offers a built-in integrity check, and what the restore procedure requires in terms of database versions and keys.
Why do time synchronization and log forwarding matter inside an air-gapped enclave?
Accurate time and complete logs are what make the audit trail credible when someone asks who changed or viewed a record. Without an internal time source, timestamps on imports, edits and backups drift, and events from different hosts can no longer be ordered. Run an internal NTP service that syncs to a reference you control, and forward archive, identity, scanner and host logs to a collector inside the enclave with its own retention. Confirm with the vendor which events the archive writes to its audit log, whether logs can be exported in a standard format, and whether the logs cover reads as well as writes. Map the retention period to your own records policy.
Evidence auditors and examiners ask for from an enclave archive
This table maps each evidence type an assessor is likely to request to the component that produces it inside the enclave. Read each row as a question to answer before go-live: which tool writes the record, where it is stored, and who can export it. DeployOpen prepares this evidence for your assessment, but independent auditors and certification bodies issue any audit report or attestation.
| Evidence | Produced by | What the assessor checks |
|---|---|---|
| Transfer manifests and hash records | Import staging folder, transfer script and manifest file kept with each package | Each file carried across the boundary matches its recorded hash and has a named approver and date |
| Audit logs of document access | Document management application audit trail, forwarded to a log store inside the enclave | Who viewed, downloaded, changed or deleted a document, when, and from which account |
| Audit logs of document changes | Application version history plus host and database logs for administrative actions | Changes to metadata, retention rules and permissions are attributable and cannot be silently edited |
| Backup and restore test records | Backup job reports, restore test logs and checksum comparisons on a restored sample | Backups are complete, encrypted, stored separately and restored successfully on a recorded schedule |
| Update change records with integrity verification | Change tickets, signed or hashed container image lists and offline package checksums | Each image, OCR language pack and rule set crossing the air gap was approved, verified and traceable to its source |
| Access review exports | Directory or application role exports taken at each review cycle, with reviewer sign-off | Only current staff hold access, leavers are removed, and privileged roles are reviewed separately |
| Retention and disposal logs | Retention rule configuration export and deletion records from the archive | Records are kept for the period the schedule requires and disposal follows an approved, logged process |
| Key and encryption custody records | Key management procedure, key rotation logs and offline key backup register | Keys are held apart from the archive data and changes to them are approved and recorded |
What to ask an implementation partner before an air-gapped build
Start with the offline bill of materials. Ask the partner to list every container image, base layer, OCR language pack, font, scanner driver and dependency the archive needs, with versions and checksums, before any work begins. Ask how that list will be produced, who signs off on it, and how it will be reconciled when a component changes. Ask how each package is verified before it crosses the boundary, including checksum and signature checks and the record kept of what was imported, when, and by whom. This is the practical control behind the software integrity and authenticity expectations in NERC CIP-013-2, and it is the evidence an assessor will ask to see. Confirm whether the verification steps are documented as a repeatable procedure rather than a one-time check.
Next, test the intake path and the recovery path. Ask how offline OCR language packs are installed, pinned and tested for the languages your records actually use, and whether a language pack update is treated as a controlled change. For scanners, ask for an intake test plan that covers import folders inside the enclave, file naming, a sample batch of mixed paper quality, and a documented result for OCR accuracy. For restore, require a restore test performed inside the enclave on a copy of the backup set, with the integrity check results recorded. Ask for the update procedure and rollback steps in writing, including how a new release is staged on removable media, scanned, imported, tested, and reversed if it fails. Finally, confirm paid-edition requirements for offline use. Air-gapped deployment is often limited to commercial editions, so get the edition, license terms and support entitlement named in the quote, and confirm the chosen platform supports offline operation under that license.
Before work starts, ask for the written scope and deliverables. The scope should name the systems, the enclave boundary, the roles that administer and approve changes, and the handover documentation: architecture notes, runbooks for backup, restore and update, the bill of materials, verification logs, and test records. Ask which items are fixed-scope deliverables and which are optional retainers for later upgrades. Request the timeline and acceptance criteria in writing so that each test result can be checked against them. Ask the partner to confirm which vendor claims about offline support they have verified themselves, and which you must confirm directly with the vendor or your own security team.
How much effort does an air-gapped document archive take, and what does the work need from us?
What drives the effort of an air-gapped document archive?
The main drivers are the volume of media that must cross the boundary, the number of platforms in the stack, the number and type of integrations, the scanner count, and how deeply the archive is validated. Each platform adds images, language packs, configuration, backup jobs and update steps that must be built and tested offline. Media volume matters because every update, OCR language pack and rule set has to be packaged, verified and imported through your transfer process. Validation depth changes the work more than most buyers expect, because documented test evidence and change control multiply the effort of every release. Ask any partner to break its quote down by these drivers so you can see which ones you can reduce.
How long does it take to get a first working air-gapped archive?
The timeline depends on how quickly the enclave is ready and how many inputs the client can supply early. Teams usually lose the most time waiting on the network diagram, the approved media process, the identity source and the retention rules, so these should be settled before build work starts. The build then covers offline container images, the OCR setup, scanner and import folder access, backups and a restore test. Confirm the schedule with your partner in the written scope, because no duration is stated here and it varies with the number of platforms and the approval steps in your environment.
What does the client need to provide before work starts?
Prepare four inputs. First, a network diagram of the enclave that shows where the archive, scanners, backup targets and any transfer workstation sit. Second, a written media process that defines how software, language packs and updates are approved, scanned and imported. Third, the identity source the archive will use for logins and group membership, such as an existing directory service. Fourth, the retention and disposal rules that the archive must enforce. Missing any one of these usually adds rework, so ask the partner to list them as dependencies in the statement of work.
Can our internal staff run the archive after handover?
They can, if the handover includes runbooks, restore tests and a trained operator group. Day-to-day tasks include monitoring the services, checking backups, managing user accounts, and running the import and update procedures across the boundary. Staff who only watch dashboards will struggle with the transfer steps, so training should cover the offline update path and the integrity checks on each package. Ask the partner what documentation it delivers, how it rehearses a restore with your team, and whether ongoing support is offered as a separate retainer.
How do updates get across the air gap safely?
Updates arrive as packaged media that is built on a connected system, transferred through your approved process, verified and then imported inside the enclave. Each container image, OCR language pack and rule set should carry a recorded checksum, and the transfer process should log who approved each item. The integrity check is what makes this defensible. NERC CIP-013-2 is a useful reference for energy operators because it asks that supply chain procedures address verification of software integrity and authenticity of vendor software and patches. Ask the partner to show the exact verification steps and the rollback plan for a failed import.
Which licenses or paid editions might the archive need?
Some vendors reserve air-gapped deployment for paid tiers, so confirm the license before choosing a platform. Mattermost lists air-gapped deployment in its Enterprise Advanced tier, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it only on its Enterprise plan, according to those vendors' pricing pages. Plane separates its Community edition under AGPL-3.0 from Commercial and Airgapped editions that are proprietary. Check each component in the stack against the current vendor terms, and ask your partner to list the license tier for every platform in the written scope.
Is an air-gapped archive more expensive to support than a connected one?
It usually carries more recurring work, because every security update, OCR improvement and vulnerability feed must be carried across the boundary by hand. Costs recur in staff time for transfers, testing and documentation, and in any retainer for upgrades and support. Initial build costs are one-time, but the transfer cycle repeats for the life of the archive. To compare options, ask for a quote that separates one-time build work from recurring update, support and testing work, and that states how many update cycles it assumes per year.
How DeployOpen scopes, builds and supports an enclave archive
The sequence moves an archive from a written scope to a tested, documented system inside the client's disconnected network, with every package and update checked before it crosses the boundary. Each step ends with a named output the client can inspect.
Agree the scope in writing
DeployOpen and the client agree a fixed scope in writing before work starts. The agreement covers the platform (for example Paperless-ngx or Alfresco Community Edition), the document types and volumes in scope, the scanners and import paths, the retention rules, the restore objectives the client needs to test against, and who on each side signs off each deliverable. The output is the signed scope document, which sets the basis for the quote. Confirm with DeployOpen which deliverables are included before signing, since DeployOpen does not publish a price list and quotes follow from this written scope.
Build the offline bill of materials
Before anything enters the enclave, DeployOpen lists every artifact the system needs: container images, base operating system packages, OCR language packs, database and search components, and any scanner drivers. The list records each item's name, version and source checksum. The client's security team reviews the list against its own approved software rules. The output is an agreed offline bill of materials that the transfer process will follow exactly.
Verify integrity before transfer
Each package is downloaded on a connected staging system, checked against published checksums or signatures, scanned for known vulnerabilities, and then packaged into a transfer set. Supply chain controls such as the verification of software integrity and authenticity described in NERC CIP-013-2 can guide the procedure where the client is subject to them. The output is a signed transfer manifest and a verification log that the client keeps as evidence of what entered the enclave.
Build and harden inside the enclave
Engineers install the platform from the transfer set on infrastructure inside the client's network, using a private registry for container images and no outbound calls to public repositories. They configure authentication, role-based permissions, encryption where the platform does not provide it, audit logging, time synchronization and network restrictions, then record each setting. The output is a hardened build with a configuration baseline that matches the agreed scope.
Test scanner intake and restore
DeployOpen runs the intake paths the client will use in production: a scanner writing to an import folder, a file dropped by a service account, and a bulk batch of sample documents. Each path is checked for OCR output, metadata, permissions and audit entries. A restore test then rebuilds the archive from backup on a separate system and compares document counts and checksums. The output is a test report listing each case, its result and any defects the client has accepted or asked to fix.
Hand over documentation and runbooks
DeployOpen delivers the system documentation, the configuration baseline, the backup and restore runbook, the update procedure for crossing the air gap, and the list of controls and evidence the client can present in an assessment. Staff are trained on administration and routine checks. The output is a handover package accepted in writing by the client, so the client can operate the archive without depending on the implementer for routine work.
Support upgrades across the air gap
Where the client wants ongoing help, a retainer covers repeating the bill of materials, verification and transfer process for each vendor release, testing the upgrade in a non-production enclave copy, and applying it to production. Confirm with DeployOpen which upgrade, testing and response commitments a retainer includes, since these are set out in the written agreement rather than assumed. The output for each cycle is a release record showing what changed, what was tested and what was approved.
