Why an air-gapped intranet is a different build
An intranet for a network with no route to the internet is an ordinary intranet in its features, but it is a different build. Installation, module updates, directory sign-in and content moderation must all work without outbound connections, so the platform has to have a documented offline path before anything else is evaluated. Many candidates fail that test on paper: they assume package repositories, license checks, external fonts, embedded media or push notifications that reach out to a vendor. Treat the offline path as a go or no-go gate, and ask each vendor to show it in writing for the exact edition and version you plan to run.
Licensing is the check to run early. Several vendors reserve air-gapped support for paid editions. Mattermost lists air-gapped deployment under Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Element offers a separate Sovereign edition for air-gapped deployments alongside its free AGPL Community edition. Confirm which tier includes offline installation, offline updates and offline license validation, and whether support terms apply inside the enclave. Plane follows a similar pattern, with a distinct Airgapped edition that is proprietary, so the open-source Community code is not automatically the air-gapped build. A licensing surprise discovered after design costs more than one discovered during shortlisting.
DeployOpen plans, installs, hardens, documents and supports the self-hosted system inside your enclave, including the offline transfer procedure for packages and updates. DeployOpen does not issue audit reports, attestations or certifications. Evidence it prepares, such as configuration records, access reviews and update logs, supports assessments that independent auditors and certification bodies perform. Ask your compliance lead early which evidence the assessor expects, and confirm with the platform vendor which offline update and license artifacts they will supply for your records.
Which requirements shape an air-gapped intranet build
This table maps each regulatory or control requirement that can reach an air-gapped intranet to the build decision it drives and the evidence an assessor will expect. Read it as a starting list: the intranet only falls under a rule where it stores, transmits or controls the regulated data, so confirm applicability with counsel and your assessor before you design around it.
| Requirement | What it asks for | Build consequence | Evidence to keep |
|---|---|---|---|
| HIPAA Security Rule, 164.312(b) audit controls | Record and examine activity in systems that contain ePHI, so access and changes can be reviewed after the fact. | Enable application audit logs for page views, edits, permission changes and admin actions, and ship them to a log store inside the enclave with its own retention and access controls. | Log configuration exports, sample audit records, review procedure and records of who examined them. |
| HIPAA Security Rule, 164.312(e)(1) transmission security | Guard against unauthorized access to ePHI sent over an electronic communications network. | Keep all traffic on enclave links with TLS between users, the web server and the database; disable any feature that sends content to outside endpoints, such as link previews or hosted media. | Network diagrams, TLS configuration results, and a list of disabled outbound features. |
| SEC Rule 17a-4(b)(4) communications retention | Preserve originals of business communications for not less than three years, including inter-office communications, where the platform carries them. | Treat intranet posts, comments and messages that record business decisions as records: configure retention, prevent silent deletion and confirm the export format with your archive owner. | Retention settings, legal hold procedure, and proof that deletions are logged and recoverable. |
| NERC CIP-013-2 software integrity and authenticity | Supply chain processes must verify integrity and authenticity of vendor software and patches before they enter the environment. | Every package, container image and module update crosses the boundary on signed, hashed media. Stand up a local package mirror and registry so nothing is pulled from the internet at install or update time. | Hash and signature verification logs, import approval records, and the mirror's inventory of carried artifacts. |
| NERC CIP-005-7 remote access paths | Interactive remote access to in-scope systems must pass through an intermediate system with encryption and multi-factor authentication, and active vendor sessions must be detectable and disableable. | Do not give the intranet a direct remote path for vendor support. Route any admin or vendor access through the approved intermediate system, and keep the intranet's admin console off general user networks. | Remote access architecture, MFA configuration, and session detection and disable test records. |
| Outbound content and third-party requests | Not a single rule, but assessors look for uncontrolled data egress and external dependencies in controlled environments. | Self-host fonts, scripts, icons and themes. Disable push notification services and any external embed or widget that calls an outside host, and block these at the network layer as well. | Dependency inventory, browser requests captured from a test session, and firewall rules showing blocked destinations. |
| Applicability and scope | Regulations apply to the systems and data that fall within their scope, not to a platform by default. | Classify what the intranet will hold before design. Spaces holding regulated records or controlled information may need stricter controls than general news spaces. | Data classification register and a counsel or compliance sign-off on scope. |
Which open-source intranet platforms fit an enclave
An enclave intranet has to install from offline media, update without reaching a vendor, and keep every service inside the boundary. The options below differ mainly in license, packaging for offline use, and whether the edition you need is free or paid, so check those before you check features.
XWiki for policy and structured knowledge
XWiki is licensed under the LGPL 2.1, and its official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB variants, so the database choice can match what your enclave already operates. Its long term support line suits enclaves that cannot upgrade often, because security fixes arrive on a slower schedule than the stable line. The Pro connectors need review before use: several depend on external services such as Office365 or Google Apps, which an isolated network cannot reach. Confirm which Pro applications run without outbound calls.
Nextcloud as a files and portal layer
Nextcloud Server is licensed under AGPL-3.0 and covers file sharing, internal pages and collaboration in one server. It fits enclaves that want files and a simple portal under one identity layer, but its fit depends on the surrounding stack. Office editing, chat and mail each need a separate component, and those components have their own offline and license conditions. Map every add-on your users will need, then confirm each one installs from local packages.
BookStack for simple policy wikis
BookStack is an MIT-licensed wiki organized into books, chapters and pages, which suits policy manuals, standard operating procedures and approval-driven content. Its small footprint makes it easier to rebuild from a transferred package and to keep under change control. The gap is social features and fine-grained publishing workflows, so pair it with a news tool if staff expect comments and reactions. Verify how its releases and dependencies are packaged so you can review each upgrade before moving it across the boundary.
HumHub as the social intranet option
HumHub provides spaces, activity streams and an employee directory, which matches a social intranet more closely than a wiki does. Confirm its offline installation path and which edition supplies the directory and SSO connectors your enclave requires, because those features may sit outside the free edition. Test how user profiles and notifications behave without outbound email or push services, since a social feed that depends on them will degrade silently. Treat the edition question as the first decision in the project.
Paid editions for chat and planning
Mattermost lists air-gapped deployment in its Enterprise Advanced plan, Rocket.Chat excludes it from the free Starter plan, and Plane offers a separate Airgapped edition that is proprietary. Element offers a Sovereign edition for air-gapped deployments alongside its free AGPL Community edition. If your intranet needs chat or task boards inside the enclave, budget for the licensed edition from the start and confirm the offline terms in writing before the design is set.
How offline installation and module updates reach the enclave
Every artifact that enters an air-gapped enclave should follow one controlled transfer pattern: container images, OS packages, module archives, language packs and documentation are downloaded or built outside the boundary, scanned, hashed and signed, carried across on approved media, and then imported into a local container registry and package mirror inside the enclave. Installers and cluster tooling then read only from those internal sources. The same pattern applies to every vendor on the platform, so the transfer procedure should be written once and reused for each release.
Documented offline installs show how the pieces fit together. The Kubernetes kubeadm workflow lets you list and pull control plane images ahead of time, and the --image-repository flag points kubeadm init at a private registry, so the cluster never reaches a public one. GitLab publishes separate guidance for self-managed offline instances and for its security scanners. Use these as reference points when you ask an intranet implementation partner how each component will be pulled, verified and imported, and who keeps the local registry and mirror current.
Update cadence and module compatibility must be planned as one bundle, not as separate upgrades. A new core release may require matching versions of extensions, themes, database drivers or language packs, and a security fix for one component can arrive while another is pinned. Agree a release calendar with the business owner, define which versions are approved for the enclave, and test each bundle in a staging enclave before import. Confirm in writing how each vendor delivers offline updates, whether through a signed archive, an offline repository or a new media image, what it includes, and how rollback works, because the answer differs by product and edition.
How deployment constraints change the design by enclave type
In a fully disconnected classified enclave, nothing crosses the boundary except through the accredited transfer process. The intranet platform, its container images, its PHP or Java dependencies, its language packs and its theme assets must all arrive as reviewed media, so the build is an offline bundle assembled and checked outside the enclave. Identity is sourced from the enclave's own directory, and every account, group and role is mapped to a directory object that already exists inside the boundary. Moderation is performed by named administrators inside the enclave, and any review queue, comment filter or notification must work without reaching a public service.
- Pulled content: Only signed, scanned packages and approved content batches enter. Keep a manifest of every artifact and its checksum, and record who approved each import.
- Directory identity: Bind authentication to the enclave directory only. Remove any external SSO provider, public identity endpoint or cloud-hosted login from the configuration.
- Embeds and push: Disable external embeds, remote fonts, analytics scripts and mobile push relays. Verify this with a network test from inside the enclave, not only from the admin console.
- Moderation: Review queues, takedown and audit of posts stay on local administrators, with reviewers cleared to the classification level of the spaces they moderate.
- Local logging: Web server, application, authentication and admin audit logs remain on enclave storage and are forwarded only to enclave log systems.
Confirm with your accreditation authority which transfer path, scanning standard and media rules apply before scoping the offline bundle.
A disconnected operational network with a one-way transfer, often a data diode or a controlled media transfer point, accepts data in one direction only. The intranet can receive updates and approved content from the upstream side, but it cannot send anything back, including logs or user activity. That shapes the update cadence: module updates, security patches and new content move in discrete batches, and each batch needs a test install on a staging copy before it reaches production. Directory data is usually a periodic export rather than a live feed, so account changes lag, and that lag should be designed for.
- Pulled content: Updates and content arrive in scheduled batches. Test each batch on a staging instance inside the operational network before promotion.
- Directory identity: Use an exported copy of the directory, refreshed on a set schedule. Define how leavers are disabled between refreshes, because the one-way path blocks live revocation.
- Embeds and push: Remove anything that calls out, including update checks and remote asset loads. Confirm that the platform's update check can be turned off without breaking the admin console.
- Moderation: Moderators work inside the network. Publishing decisions should be recorded locally, since the outside world will not see them.
- Local logging: Logs stay local for the operations team. If the diode carries logs out, confirm with the data owner what is allowed and how it is labeled.
Check how the transfer device handles file types, sizes and malformed archives, because those limits decide which packages the offline bundle can contain.
A controlled network has a connection to outside services, but every session passes through a broker, proxy or intermediate system that enforces policy and records activity. This model is closest to a standard intranet, yet it still restricts outbound calls to a short approved list. Updates can be pulled through a mirror or internal repository that the broker allows, and the mirror should be refreshed from verified sources so that the package list is known and reviewed. Directory integration can be live, with the intranet bound to the corporate directory through a controlled path, and moderation can use the same review tools as the rest of the organization.
- Pulled content: Pull packages from an internal mirror that is refreshed from verified sources. Keep the approved destination list short and documented.
- Directory identity: Live directory binding is possible through the brokered path. Confirm that multi-factor authentication and session policy come from the broker or the directory, and that the intranet honors them.
- Embeds and push: Block third-party embeds at the proxy and at the application. Push and mobile notification services are usually the first items to deny.
- Moderation: Use central moderator roles with audit trails, and separate moderation of confidential spaces from general news.
- Local logging: Security-relevant logs, especially session and administrative activity, should remain in the controlled network's log store even when a copy is forwarded to a monitoring service. Confirm the retention rules with your records team.
A useful check is whether the broker can show every connection the intranet attempts, including those that are blocked.
Integration points that must stay inside the enclave
An intranet in a disconnected network is only as offline as its weakest integration. Each point below either resolves inside the enclave or gets removed, and each needs an owner, a tested failure path and evidence that nothing leaves the boundary.
Internal directory integration
Sign-in and profile data should come from the enclave's own LDAP directory or SAML identity provider, with no fallback to a cloud identity service. Confirm with the vendor which edition supports LDAP and SAML, since that often determines whether this works at all. Test group mapping, account deprovisioning and what happens when the directory is unreachable, because a stale directory can keep former staff inside spaces they should have left.
File and document storage
Attachments, policy documents and uploaded media must live on storage inside the enclave, with no sync clients or previews that call home. Decide which file types are allowed and whether document editing runs on a self-hosted office server. Check that backups and replicas stay inside the same boundary and that restore has been tested on an isolated network.
Search indexing
Search should index only content stored inside the enclave, using a search service deployed alongside the intranet rather than a hosted index. Confirm that crawlers and connectors do not reach external sources and that index files are stored on enclave media. Plan a reindex procedure for restored content, because a search index built on one network may not match what is available on another.
Mail notifications through an internal relay
Notification emails for mentions, approvals and read receipts should route through an internal SMTP relay that the enclave operates, never a public email service. Confirm the relay's logging, its retention and which accounts may send. Email alerts also expose the intranet to a second system, so note which notification types carry sensitive text and whether they should be suppressed for classified spaces.
Audit and security monitoring
Access logs from the intranet must feed monitoring that also runs offline. Wazuh publishes an offline installation guide for systems without internet connectivity, and Security Onion supports airgap installs and updates from newer ISO media. Confirm each tool's offline rule and vulnerability content, and check that the intranet's audit records reach the monitoring platform without a cloud forwarder.
Content review and moderation workflow
Moderation must run inside the enclave, with reviewers, queues and approval records held on enclave systems. Define who reviews posts in classified or sensitive spaces, how flagged content is held, and how removals are recorded. Remove or replace any external embed, hosted font, analytics tag or push notification service, because each one sends traffic outside the boundary and can leak that staff visited a page.
Rollout phases and the output of each
The sequence moves an intranet from requirements to an enclave installation that a security team can accept, then to content, access tests and evidence, and finally into a supported update cycle. Each phase closes with a named artifact so the accreditation owner can see what was built, tested and handed over.
Run the classification and requirements workshop
The security owner, the intranet product owner, the directory administrator and the enclave operator agree the classification of content, the audiences and spaces, the authentication model and the boundary rules for what may cross into the enclave. DeployOpen facilitates the session and writes the results into a scope document that both sides sign. The step is done when every space has a named owner, every integration is either approved or removed, and the open items list has an accountable person against each entry.
Build the offline bundle and vet artifacts
On a connected build network, DeployOpen assembles every container image, package, language dependency, theme and extension the intranet needs, then records each one in a bill of materials with versions, hashes and license terms. The bundle is scanned and checked for integrity and authenticity before it is signed and moved across the transfer boundary under your approved process. The output is a signed bill of materials and a transfer record. Confirm with your accreditor which scanning and signing steps they require, since NERC CIP-013-2 expects software integrity and authenticity checks for vendor software and patches where that standard applies.
Install inside the enclave and connect the directory
Inside the isolated network, the team installs the platform from the offline bundle, configures storage, backups and logging, and connects the internal directory for authentication and group membership. Installation runs without any outbound calls, and the team confirms that no external fonts, scripts, analytics, map tiles or push notification services are reachable. The output is an install record listing versions, configuration baselines, directory bindings and the results of a network egress check.
Migrate content through the transfer gate
Content is brought in as reviewed batches, each one passing through the same transfer gate used for software. Owners of each space confirm that the material is classified correctly and does not contain items that belong on a more restricted system. Migration logs record counts, failures and exceptions per batch, and attachments are checked before they are accepted. The step is complete when each batch has a sign-off from its owner and the migration log reconciles against the source inventory.
Test moderation and access models
The team runs scripted test cases against the access model: members of each group should see their spaces and nothing else, restricted posts should stay hidden from unauthorized users, and moderators should be able to remove or lock content with their actions logged. Test accounts cover each role, including administrators, external-facing roles where they exist, and users removed from the directory. Results are recorded with pass or fail status, the tester, and the retest for each failure. The output is a signed test results report.
Capture evidence and hand over the runbook
DeployOpen assembles an evidence pack that maps configuration baselines, access test results, audit log settings, backup and restore tests, and the signed bill of materials to the control objectives your assessor uses. The pack is reviewed with your compliance lead, who decides what the assessor receives. The handover includes an operations runbook covering start and stop procedures, backup and restore, account administration, moderation procedures and incident contacts. Done means the evidence pack is accepted by the control owner and the runbook has been walked through with your operators.
Run the supported update cycle
Updates follow the same path as the initial build: new releases are reviewed, rebuilt into an offline bundle, vetted, signed and installed inside the enclave, with a regression test pass against the access and moderation cases. Each cycle produces a new bill of materials, an updated install record and a change entry in the evidence pack. Ask any partner to state in writing how security patches, feature releases and end-of-support dates are tracked, and who approves each transfer. Ongoing support of this kind is available as a retainer and is scoped in writing.
Evidence auditors ask for and which component produces it
This table maps the evidence assessors commonly request for an intranet inside a disconnected enclave to the component or process that produces it. Read each row as a question an assessor will ask, then check which layer must generate the record. DeployOpen prepares this evidence for independent assessors, who issue any opinion.
| Evidence | Produced by | What to confirm |
|---|---|---|
| Access logs for intranet sign-ins and admin actions | Intranet application logging, forwarded to a central log store inside the enclave | Logs include user, time, source and action, and forwarding works without external services |
| Audit trail of content changes, edits and deletions | Intranet version history and audit features, such as XWiki page history or HumHub content records | History survives retention rules and cannot be silently purged by moderators |
| Retention settings for communications and records | Platform retention configuration, plus the enclave's records policy | Whether the platform's retention settings match the records rules that apply to your sector |
| Artifact hashes for every package carried across the boundary | Transfer process: hash manifests generated at the source and checked on import | Who verifies hashes, where the manifest is stored and whether a failed check blocks the import |
| Transfer records for media moving across the isolated boundary | Cross-domain transfer log kept by the enclave operator, with media custody records | Named approver, timestamps and media identifiers for each transfer |
| Change records for offline module and platform updates | Change management system or ITSM ticket linked to each offline update package | Pre-update backup, test result and rollback plan attached to each change |
| Vulnerability scan results from an offline repository | Scanner such as Wazuh using an offline vulnerability repository, with dated feed versions recorded | Feed age at scan time and how scans cover the intranet host, database and web server |
| Directory and access control configuration | Directory integration settings and group-to-space mappings exported on a schedule | Evidence that access to restricted spaces matches the approved access model |
| Software integrity and supply chain records for vendor packages | Procurement and verification records for each vendor package and patch | Signature or checksum verification for every package, with the verifier identified |
What buyers ask before running an intranet in an enclave
What drives the cost of an air-gapped intranet?
Cost comes from four areas: the edition or subscription you need, the enclave hosting, the vetting and transfer process for every software and content transfer, and the staff who moderate content. Edition licensing matters because air-gapped support is often a paid-edition feature. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat excludes it from its free Starter plan, so check the license tier before you design around a platform. Ask any partner to split the quote into one-time items (installation, hardening, migration, training) and recurring items (subscriptions, support, update transfers, moderation time). Hosting costs depend on your own data center or accredited enclave, so confirm those with your infrastructure team rather than assuming them.
How long does an air-gapped intranet take to deploy?
The timeline depends on scope, not on a fixed duration. The main variables are the number of spaces and audiences, how many directory sources must be integrated, how much content must be migrated and reviewed before it enters the enclave, and how long your approval and transfer process takes. Offline installation adds steps that connected deployments skip, such as preparing every package and container image in advance. Kubernetes, for example, can be built without internet access, but only after the control plane images are fetched and pushed to a private registry first. Ask for a written scope with milestones that include security approval gates, not just build tasks.
What does the client need to provide for an enclave intranet?
The client provides the decisions and access that only the organization can give. These include a data classification for each space and content type, which determines what may be published and who can read it. You also need directory access for the integration, usually a service account and agreed attribute mappings, along with approval from your security authority for each transfer of software, updates and content across the boundary. Name one owner for classification and one for transfer approvals before the work starts, because delays in these two areas are the most common cause of schedule slips. Confirm the exact approval steps and their lead times with your accreditation or security team.
Can our own team run an air-gapped intranet without a partner?
Yes, if you have skilled staff and the vendor documentation to support them. Your team will need experience with the chosen platform, its database and web server, container or package management, directory integration and offline update procedures. Some open-source operations platforms publish offline guidance, such as Wazuh's offline installation guide and GitLab's documentation for self-managed offline environments, which shows the kind of material to review before you commit. The question to answer honestly is who will patch, back up and restore the system when no one outside the enclave is available. A partner can take that work under a fixed-scope engagement or a retainer, but the choice should follow your staffing, not a default.
Does XWiki Pro or Confluence migration work offline?
Confirm this before you rely on it, because the answer depends on the connectors, the license terms and where the migration runs. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, along with connectors for Google Apps, Office365 and OnlyOffice, and those connectors reach external services, so they may not apply inside an enclave. XWiki's Confluence Migrator Pro migrates spaces, pages, users, groups, permissions, attachments and metadata, keeps page history but not attachment history, and is priced from 2000 EUR according to XWiki Store. Ask XWiki SAS in writing whether the migrator and any Pro modules can be installed and licensed in a disconnected network, and whether license validation requires internet access.
How are software and module updates delivered without internet access?
Updates arrive as transferred media that have been checked before they enter the enclave. The usual pattern is to download the release on a connected staging system, verify its integrity and authenticity, scan it, record its hash, and then move it across the boundary through your approved transfer process. Inside the enclave, you apply the update to a test copy first, then to production. Security Onion shows this model: its soup tool updates from newer ISO media in airgap mode. NERC CIP-013-2 requires utilities to address verification of software integrity and authenticity for vendor software and patches, which is a useful benchmark even outside the energy sector. Ask your partner for a written update runbook, a rollback plan and a schedule that matches the vendor's release cadence.
Who moderates content inside the enclave, and how much effort does it take?
Moderation is ongoing work, and it is usually the largest recurring cost after the platform itself. Inside an enclave, moderators work only with content that has already been classified, so the workflow needs clear rules for who can post, who approves news and which spaces are restricted. Plan for named moderators in each business area, escalation paths for content that may be classified higher than it was labeled, and audit logs that show who changed what. The effort depends on post volume, the number of spaces and how many people publish, so ask your partner to estimate it from your own audience model rather than from a generic figure. Compliance frameworks such as HIPAA's audit control requirement under 45 CFR 164.312(b) expect activity in systems with sensitive data to be recorded and reviewed, which makes moderation logging part of the design.
What to ask an implementation partner for an enclave
Start with the update path, because it decides whether the enclave stays supportable. Ask the partner to show, on a disconnected test system, how a module update arrives on removable media, how it is installed, and what record proves the installed version matches the approved artifact. Ask for the exact list of packages, container images and language dependencies that must be carried across the boundary, and who maintains that list after handover. Then ask how artifacts are vetted and signed before they enter the enclave: which signatures are checked, against which keys, and where those keys are held. The NERC CIP-013-2 supply chain requirement on verifying software integrity and authenticity is a useful reference point for these answers, even outside the energy sector.
Next, pin down the edition and the license. Several platforms restrict air-gapped deployment to paid tiers, so ask which edition the proposed design uses, whether that edition is licensed for disconnected operation, and what the license terms say about updates, support and the number of users. For XWiki, ask whether the design relies on the LGPL 2.1 Standard edition or on XWiki Pro and a support subscription, and what the subscription covers when the system has no internet access. Ask who approves each transfer across the boundary, which roles can request one, and how each approval is logged. Ask how the directory is integrated without outbound calls: the partner should name the LDAP or Active Directory endpoint inside the enclave, the service account, the attributes synchronized, and how the intranet behaves when the directory is unreachable.
Finish with evidence and support. Ask for a written list of evidence delivered at handover, such as the installation record, the transfer logs, the signature verification output, the configuration baseline and the audit log settings, and confirm which of these your assessor will accept. Ask how audit records are retained and who can read them, since controls such as the HIPAA audit control requirement in 45 CFR 164.312(b) apply to systems holding ePHI. Ask what support looks like once the enclave is disconnected: who is on call, how security advisories reach the enclave, how long a fix takes to arrive by media, and whether the partner will rehearse an update before you need one. Get these answers in the statement of work, not in a sales call.
How DeployOpen scopes and builds an enclave intranet
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an enclave intranet, that means fixing the offline boundary, the directory integration and the moderation model in writing before any software is staged.
How we scope
- Written scope lists the enclave, user populations, spaces and the directory systems the intranet must read from.
- Scope records which content types, attachments and embeds are permitted, and which are blocked at the boundary.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Build plan covers offline installation media, container images and packages staged through a controlled transfer process.
- Directory integration is configured against the internal identity source, with no external identity or push service calls.
- Moderation roles, content review steps and admin access are configured and tested inside the enclave.
How we hand over
- Handover includes installation, configuration and hardening documentation written for the enclave operations team.
- Runbooks cover offline module updates, verification of each package before it crosses the boundary, and rollback steps.
- Compliance evidence packs list the controls, configuration records and test results your assessors will ask for.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers, scoped separately from the build.
- Upgrade cycles are planned around the transfer process so each release is reviewed before it enters the enclave.
- Confirm with DeployOpen which support tier, response expectations and staffing model apply to your enclave.
