EXPLAINER

What is IMPEX?

Organisations working across defence, government and other high-assurance environments often need to move information between systems that have been deliberately separated. One network may be internet-connected, another may be isolated, and a third may operate under different security rules or at a different classification. The separation protects the more sensitive environment, but the work still depends on information moving in and out.

IMPEX is the controlled import and export process used to make that movement possible. It brings together technology, policy, review and evidence so that files do not simply cross a boundary because a user needs them. They are checked against defined rules, approved where necessary, transferred through an authorised route and recorded in a way that can be audited later.

The exact design varies. A small isolated environment may rely on tightly governed removable media and a scanning station. A larger programme may use an automated cross-domain solution, one-way transfer technology, content inspection and formal release workflows. In each case, the purpose is the same: allow the information required for delivery to move without quietly undermining the boundary that was created to protect the system.

What does IMPEX mean?

IMPEX is shorthand for import and export. In secure systems, the term describes the governed movement of data into or out of a security domain. A domain may be a network, platform or collection of systems that shares a common level of trust, access model and security policy.

The important word is governed. Copying a file onto removable media and carrying it to another network is technically an import or export, but it is not necessarily a controlled IMPEX process. A credible process establishes which information may move, who can request the transfer, which checks are required, who can authorise release and how the action is recorded.

IMPEX can refer to the overall operating process, the technical capability supporting it or both. It is therefore better understood as part of a wider security architecture than as a single product. The right design depends on the sensitivity of the information, the trust relationship between the domains, the permitted direction of travel and the consequences if the transfer goes wrong.

Why is IMPEX needed?

Secure environments are separated because direct connectivity would introduce an unacceptable route for compromise or disclosure. An air-gapped network may be protected from internet-borne threats. A sensitive programme environment may be isolated from the wider corporate estate. Two organisations may also need to exchange information while retaining different security policies and administrative control.

That separation reduces exposure, but it does not remove operational dependency. Teams still need software updates, threat information, technical drawings, test evidence, reports, datasets, configuration files and other material. They may also need to release completed work, approved extracts or reporting from the protected environment to customers and delivery partners.

Without an authorised route, the pressure to deliver does not disappear. It tends to reappear as workarounds: personal storage devices, unmanaged transfer tools, duplicated systems, informal approvals or files being recreated manually on the other side of the boundary. These methods can be slow and difficult to govern, and some actively weaken the assurance the isolated environment was intended to provide.

IMPEX gives the organisation a usable route through the boundary. It does not make every transfer safe or appropriate. It creates a repeatable way to make the decision, apply the required controls and preserve evidence of what happened.

Import and export present different risks

The word IMPEX often makes import and export sound like two directions through the same technical gate. In practice, the security problem changes depending on which way the information is moving.

Importing into a protected environment

An import can introduce hostile or malformed content into a domain that has deliberately limited its exposure. Malware is the obvious concern, but it is not the only one. A file may exploit a vulnerability in the application that opens it, contain active content or macros, use an unexpected format, carry misleading metadata or create a dependency on software that the protected environment does not permit.

The import route therefore needs to protect the integrity and availability of the receiving system. Controls may include source validation, file type restrictions, multiple scanning engines, content disarm and reconstruction, quarantine, manual inspection, testing in a separate environment and confirmation that the receiving system can process the content safely. The measures should reflect the type of data and the harm that could follow from a successful import attack.

Exporting from a protected environment

An export creates a different concern: information may be released to a domain where it will receive less protection, reach a wider audience or become harder to recall. A technically clean file can still be an unacceptable export if it contains sensitive content, hidden data, comments, tracked changes, embedded objects, personal information or material that the requester is not authorised to release.

The export route therefore needs to control disclosure. That may involve checking the owner and protective marking, confirming the recipient and destination, reviewing the contents, removing metadata, applying redaction or sanitisation, obtaining release approval and retaining an immutable record of the decision. Automated checks can help, but accountability for release often remains a human and organisational responsibility.

How does an IMPEX process work?

There is no single workflow that applies to every environment. A proportionate process usually contains the following stages, with additional controls introduced where the risk requires them.

1. A transfer is requested. The user identifies the file or dataset, the source and destination domains, the purpose of the transfer, the recipient and any relevant handling or classification requirements.
2. The request is validated. The process confirms that the user is authorised, the transfer has a legitimate business need and the proposed route is approved for that type of information.
3. The content is checked. Files may be scanned for malware, validated against permitted formats, inspected for active content, analysed for hidden data and assessed against policy rules. Some designs rebuild the file into a safer form rather than allowing the original object to pass unchanged.
4. Approval is applied. Low-risk transfers may be released automatically when all policy conditions are satisfied. Higher-risk exports, unusual formats or sensitive content may require independent review and formal authorisation.
5. The data crosses the boundary. The approved content moves through the authorised mechanism. This may be a guarded gateway, one-way transfer device, managed staging area, controlled removable media process or another cross-domain design.
6. The receiving side confirms the transfer. The destination may perform further checks before the content is made available. Failed or uncertain transfers should be quarantined rather than silently delivered.
7. The event is recorded. Logs should show who requested and approved the transfer, what moved, when it moved, which checks were applied, where it was sent and whether any exceptions occurred.

A good workflow is also designed for rejection. Users need to understand why a transfer failed, what corrective action is possible and who can make an exception decision. Otherwise, a secure route can become so opaque or slow that teams begin looking for an easier one.

What controls can support IMPEX?

The control set should be based on the data flow and the risk rather than a standard shopping list. The following measures are commonly relevant, although no single transfer requires every control.

Control area	What it is trying to establish	Typical evidence
Identity and authorisation	The requester, reviewer and approver are known and permitted to perform their roles.	Access records, role assignments and approval history
Transfer policy	The information type, direction, source, destination and transfer method are permitted.	Rulesets, allowlists, handling requirements and exceptions
Malware and content inspection	The content does not introduce a known or detectable technical threat.	Scan results, quarantine records and inspection logs
Release and disclosure control	The exported information is appropriate for the destination and recipient.	Owner confirmation, review record, redaction and release approval
Audit and monitoring	The organisation can reconstruct the transfer and identify suspicious activity.	Immutable logs, alerts, reports and investigation records
Operational assurance	The capability remains maintained, tested and effective over time.	Patch records, rule reviews, test results, incidents and service reviews

Where is IMPEX commonly used?

IMPEX is most visible in defence, national security and government environments, where information may need to move between systems operating at different classifications or under different handling rules. It is also relevant wherever separation protects a critical service or limits the route by which an attacker could reach it.

An engineering team may import approved software, patches or technical data into a standalone programme environment and export completed design evidence for customer review. An operational technology team may bring configuration updates into an industrial control environment while exporting logs for analysis. A research organisation may exchange datasets between an isolated laboratory network and a corporate analysis platform. A regulated service provider may need a controlled route between a customer-owned environment and its own support systems.

The shared characteristic is not a particular sector or classification. It is the existence of a trust boundary that cannot be treated as ordinary network connectivity.

Is IMPEX the same as a cross-domain solution?

The terms overlap, but they are not interchangeable. The National Cyber Security Centre uses cross-domain solution to describe the mechanisms and systems that connect domains with different rules, policies or levels of trust. A cross-domain solution may support file transfer, data feeds, messaging, remote access or other controlled flows.

IMPEX is narrower. It usually describes the import and export of files or data, together with the process used to approve, inspect and record that movement. An IMPEX capability may therefore be implemented using a cross-domain solution, or form one function within a broader cross-domain architecture.

This distinction matters during procurement. An organisation that asks for a cross-domain solution without defining the actual data flows may buy more complexity than it needs. An organisation that asks only for file scanning may overlook release approval, audit, workflow, operational support or the architecture needed to maintain separation. The requirement should start with the information, direction, frequency, users and risk.

Is IMPEX the same as secure collaboration?

Secure collaboration provides a controlled environment in which authorised people can communicate, share files and work together. Most activity takes place inside a common service boundary, even where the users belong to different organisations.

IMPEX is concerned with information crossing from one domain into another. A secure collaboration platform may receive information through an import process or release approved information through an export process, but collaboration and cross-domain transfer solve different parts of the operating problem.

This is particularly important for organisations that operate both connected and isolated services. A connected secure collaboration environment may be the right place for day-to-day work at OFFICIAL or OFFICIAL-SENSITIVE, while an isolated environment supports a more sensitive or deliberately disconnected activity. IMPEX provides the controlled bridge where the programme is permitted to move information between them.

Does an air gap remove the need for IMPEX?

An air gap removes direct network connectivity. It does not remove the need for information, software, updates or outputs to cross the boundary. In many isolated environments, the transfer process becomes more important because every movement has to be deliberate.

The risk is that teams interpret air-gapped as automatically secure and give less attention to removable media, transfer stations, maintenance processes and human approval. An infected or unauthorised file can still reach an isolated system if the transfer route is poorly controlled. Information can still leave the environment inappropriately if export decisions are informal or weakly evidenced.

Sustainable isolation therefore depends on a credible operating model around the technical separation. IMPEX, patch and update management, identity administration, monitoring, backup, incident response and maintenance all need defined routes that preserve the intended boundary.

What should organisations decide before implementing IMPEX?

The most useful starting point is a data-flow definition rather than a product demonstration. The organisation should be able to describe what needs to move, why it needs to move and what would happen if the wrong information crossed the boundary.

• Which source and destination domains are involved, and what trust or classification difference exists between them?
• Is the flow import, export or bidirectional, and should the two directions use different mechanisms?
• Which file types, datasets, sizes and volumes are expected, including unusual engineering or specialist formats?
• How quickly must transfers complete, and which genuinely require automation rather than a controlled manual workflow?
• Who owns the information, who requests the transfer and who has authority to approve release or accept an exception?
• Which technical checks are meaningful for the content, and what happens when a file cannot be inspected reliably?
• How will logs, approvals and evidence be retained, reviewed and made available during an incident or assurance activity?
• Who operates, patches, tests and supports the capability once it is live?

These decisions expose the real operating requirement. They also prevent the transfer route from becoming either too permissive to trust or too restrictive to use. Both outcomes are security failures: one allows uncontrolled movement, while the other pushes delivery teams towards unofficial alternatives.

The capability should also be reviewed as the programme changes. New file formats, suppliers, destinations, classifications and delivery pressures can all invalidate assumptions made at design stage. A rule that was proportionate for a small team exchanging documents may be unsuitable once automated engineering data, software packages or much larger volumes are introduced.

Who is responsible for IMPEX?

Responsibility is usually shared. System owners define the boundary and acceptable flows. Information owners decide whether material may be released. Security and architecture teams design the control model. Service teams operate the technical capability. Delivery managers establish the business need, while users remain responsible for submitting the right content and following the approved process.

A managed provider can operate scanning, workflow, logging and transfer infrastructure, but it cannot silently absorb every customer responsibility. The customer still needs to define the permitted data, approve release rules, manage users and act on exceptions. Where those responsibilities are unclear, a technically capable service can still produce weak assurance.

The operating model should therefore name the accountable roles, not simply state that IMPEX is provided. It should explain who can change a rule, who reviews alerts, who investigates a failed transfer, who approves an emergency exception and who periodically confirms that the process remains appropriate.

Controlled movement should support delivery

IMPEX exists because complete isolation and practical delivery rarely coexist without some form of controlled information movement. The boundary remains important, but so does the ability to bring in what the environment needs and release what the programme is authorised to share.

A strong IMPEX process makes that movement deliberate, inspectable and accountable. It gives users a route they can follow, gives information owners control over release and gives the organisation evidence that the boundary is being managed rather than bypassed. It also recognises that import and export are different security decisions, even when they use parts of the same infrastructure.

The most effective designs begin with the mission and the data flow. Technology then supports the operating model, rather than becoming a substitute for one.

---