Developing Cross Domain Requirements Before Acquisition

Most cross domain solution acquisitions run into trouble before a single contract is signed. The requirements documents are thin, the mission use cases are vague, and the security constraints that will ultimately drive every design decision are still being negotiated somewhere between the program office and the authorizing official. By the time a solution reaches the evaluation phase, the gaps are already baked in.

This is not a vendor problem. It is a planning problem. Cross domain requirements are among the most technically and operationally complex requirements any federal program will produce. They sit at the intersection of mission need, information security policy, network architecture, data classification, interoperability constraints, and authorization risk. Getting them right before acquisition is not optional. It is the only way to avoid costly redesigns, extended assessment timelines, and mission delays.

The challenge is that most agencies approach cross domain requirements the same way they approach other IT acquisitions. They start with a capability gap, look for available products, and try to fit a use case around what is already approved or funded. That approach fails consistently in the cross domain space because the approved product list, the operational constraints, and the authorization environment all impose requirements that must be defined upfront, not discovered during testing.

This article is a planning guide for federal programs, enterprise architects, ISSOs, and acquisition teams working through the requirements development phase of a cross domain project. The goal is to identify what needs to be documented, who needs to be involved, and how to structure requirements in a way that will hold up through acquisition, assessment, and authorization.

This is not about choosing a specific product. It is about doing the foundational work that makes any product evaluation meaningful.

Why Cross Domain Requirements Fail Before Acquisition Even Starts

The cross domain problem is not simply a matter of moving data between networks. It is a controlled transfer of information across a security boundary where every element of that transfer must be justified, filtered, validated, and authorized. That level of precision requires a degree of requirements specificity that most programs are not prepared to produce in early planning stages.

What tends to happen is that program offices start with a capability statement that sounds reasonable: “We need to move files from a classified network to an unclassified network.” That statement is not a requirement. It is the beginning of a conversation that needs to produce several dozen specific, documented, defensible requirements before anyone opens a market survey or drafts a performance work statement.

The failure modes are predictable. Requirements are written too broadly and do not address the specific data types, transfer directions, volume thresholds, or content inspection needs. Security requirements are copied from a previous program without mapping them to the actual authorization boundary. Operational requirements are missing entirely because the focus was on what the solution needs to do, not on who will operate it, how it will be monitored, and what happens when it fails. The authorizing official’s constraints are not reflected in the requirements because the AO was not engaged until after a product was already under evaluation.

These failures do not surface cleanly. They show up as extended assessment timelines, non-findings that require design changes, authority to operate delays, and ultimately mission capability gaps that could have been avoided with six to eight additional weeks of planning work at the front end. The cost of poor requirements is not paid at the requirements phase. It is paid at the worst possible time, during testing, during authorization, or after deployment when the solution cannot actually meet operational needs.

Cross domain requirements development is also uniquely complicated by the community of interest structure that governs most cross domain solutions in the defense and intelligence environments. The solution must satisfy not just the program’s own security requirements but the requirements of both the high-side and low-side network owners, and in some cases a national-level authority with its own certification process. Requirements that do not account for that multi-stakeholder environment will generate friction at every authorization checkpoint.

Defining Mission Use Cases and Data Transfer Patterns

Before any security or technical requirement can be written, the mission use case must be defined with enough specificity to drive design decisions. This means identifying not just the general purpose of the cross domain capability but the exact nature of the data being transferred, the direction of transfer, the frequency and volume of transfer, and the downstream systems that will consume or produce that data.

A mission use case that says “analysts need access to imagery from a classified source” is not sufficient. A useful mission use case specifies that analysts on an unclassified workstation need to receive downgraded imagery products in JPEG or GeoTIFF format, transferred from a classified processing system, with a maximum file size of 50 megabytes, at a frequency of approximately 200 files per day, delivered to a specific application through a defined interface. That level of specificity is what drives content inspection rules, throughput sizing, latency requirements, and filter configuration.

Data flow documentation is the practical output of this work. Each use case should produce a data flow diagram or description that maps the source system, the data type and format, the classification level, the transfer direction, the destination system, and the intended use. This documentation becomes the foundation for filter design, security policy, and authorization package development.

Transfer Direction and Data Type Matter More Than Most Programs Realize

High-to-low transfers and low-to-high transfers are not symmetric problems. A solution that handles downward transfer of structured data may require a completely different configuration, filter set, and risk posture to handle upward transfer of files from an unclassified endpoint. Many programs discover this during evaluation rather than during requirements development, which creates significant rework.

Similarly, the data type matters considerably. Structured data transfers, such as database records or formatted messages, behave differently from unstructured transfers of documents, images, or media files. Video streaming across a domain boundary involves different latency and throughput requirements than batch file transfer. Email handling involves different content inspection challenges than API-based data exchange. Each data type and transfer pattern should be documented separately and assessed for its security and operational implications before requirements are finalized.

The mission use case development process should also identify edge cases and exception handling requirements. What happens when a file fails the content inspection filter? Who receives the alert? What is the disposition of the rejected file? Is there a manual review process, and if so, who staffs it? These questions are not just operational questions. They are security design questions that need answers before a solution can be properly evaluated.

Building Security Requirements Around the Authorization Environment

Security requirements for a cross domain solution cannot be written in isolation from the authorization environment in which the solution will operate. The authorizing official, the system security plan, and the network owners on both sides of the boundary all impose constraints that directly affect what is technically possible and what is acceptable from a risk perspective. Requirements development must begin with an understanding of those constraints, not assume they can be worked out later.

The first step is engaging the AO or the AO’s designated representative early, before the requirements document is drafted. The AO’s risk tolerance shapes the entire security design. Some AOs will accept solutions with certain filter configurations. Others will require specific technical implementations, audit logging depths, or physical separation requirements. Writing security requirements without that input produces a document that may need to be substantially revised after the AO reviews it, which has real schedule and cost consequences.

Security requirements for cross domain solutions typically need to address several distinct areas. Content filtering requirements specify what types of content inspection must be applied, what file types are permitted or prohibited, and what happens to content that fails inspection. Audit and logging requirements specify what events must be recorded, the level of detail required, the retention period, and the integration with existing security information and event management infrastructure. Access control requirements specify who can administer the solution, from which network, and under what authentication constraints.

The Role of Approved Product Lists and Community Certification

Many cross domain environments require solutions that appear on an approved product list or have received community certification from a national-level authority. This requirement is not optional and it is not an implementation detail. It is a hard constraint that must appear in the requirements document and that will determine which products are even eligible for evaluation.

If a program’s requirements document does not specify whether an approved product list applies, and the acquisition team does not know to ask, the program may spend months evaluating products that cannot be authorized in the target environment. This is a common failure mode and it is entirely avoidable with adequate upfront engagement between the program office, the security team, and the relevant authorization authority.

Beyond the product list question, security requirements should also address the specific control baseline that applies. Cross domain solutions in environments with particularly sensitive data or mission-critical authorization boundaries may face control requirements that go beyond the standard NIST SP 800-53 control families typically applied to information systems. Understanding which controls apply, and at what tailoring level, is a prerequisite to writing security requirements that will pass review by the AO and the security assessor.

Programs that support cross domain solutions with well-defined security requirements at the start of acquisition consistently reach authorization faster and with fewer assessment findings than programs that treat security requirements as something to be resolved during testing. That pattern holds across agency types and classification environments.

Operational and Sustainment Requirements That Get Missed

Security and mission requirements get most of the attention in cross domain requirements development. Operational requirements get written at the last minute or carried over from a generic IT requirements template that was never designed with a cross domain context in mind. This is where programs set themselves up for sustainment problems that show up two or three years after initial deployment.

Availability and reliability requirements need to be tied to actual mission dependencies. If a cross domain solution supports a mission workflow that runs continuously, and the solution has an unscheduled outage, what is the impact? Can users wait for a repair window that takes several hours? Or does the mission require recovery within minutes? The answer to that question drives architecture decisions around redundancy, failover, and monitoring that must be addressed before acquisition, not after a production outage makes them obvious.

Latency and throughput requirements need to reflect actual user experience expectations, not theoretical maximums. A solution that handles 50 megabyte file transfers without performance degradation under normal load may behave very differently when the mission creates a surge demand event with several hundred simultaneous transfers. Sizing requirements should be based on peak load scenarios, not average load scenarios, and they should be documented with enough specificity to evaluate competing solutions against a common standard.

Administrator access requirements are frequently underdocumented. Who will administer the solution? From which network? Under what authentication mechanism? Cross domain solutions often impose specific constraints on administrative access because the administrative interface itself can represent a risk to the security boundary. If the program expects to administer the solution from the low-side network, and the security architecture requires high-side administrative access only, that is a conflict that needs to be resolved in requirements, not discovered during deployment.

Patching and update requirements are among the most difficult sustainment issues in cross domain environments. Many solutions in sensitive authorization environments cannot receive updates on a standard enterprise patch cycle because every update may require re-assessment before it can be deployed. Requirements should specify how patching is expected to be handled, what the acceptable lag time is between patch release and deployment, and who is responsible for coordinating the re-assessment process when updates affect security-relevant components.

Staffing assumptions also need to be documented. A cross domain solution that requires a dedicated engineer on each shift to manage filter rules and respond to incidents may be technically capable but operationally unsustainable for a small program office with a limited security operations footprint. Requirements should reflect realistic staffing constraints and specify what level of operational support the solution must be able to deliver within those constraints.

Planning Documents That Must Exist Before Acquisition

Requirements for a cross domain solution do not live in a single document. They are distributed across several planning artifacts that must exist and be internally consistent before an acquisition can produce meaningful results. Programs that lack these documents going into a market survey or competitive solicitation are effectively asking vendors to define requirements for them, which is how misaligned proposals get selected and how programs end up with solutions that do not fit the environment.

Each of these documents feeds into the acquisition package in a different way. The mission needs statement and use case documentation shape the performance work statement and the evaluation criteria. The security requirements document informs the system security plan and the assessment test plan. The operational requirements document drives the service level expectations and the sustainment provisions of the contract. The network architecture documentation gives evaluators and eventually the installer the information they need to assess integration feasibility.

The concept of operations deserves particular attention because it is often treated as a post-deployment artifact rather than a requirements-phase deliverable. Writing a concept of operations before acquisition forces the program to think through who will actually operate the solution on day one, what procedures they will follow, and what organizational responsibilities will need to be established. That thinking often surfaces requirements that were not obvious from the use case or security perspective alone.

Common Mistakes in Cross Domain Requirements Development

The same mistakes appear across programs in different agencies and different classification environments, often because requirements development is being driven by people who understand either the mission or the security constraints but not both together. Cross domain requirements sit at that intersection, and the gaps between those two domains of expertise are where the most costly errors occur.

Writing requirements around a specific product rather than around actual mission and security needs is among the most frequent mistakes. When a program already knows what product it wants, the requirements tend to be written to match that product’s capabilities rather than to describe what the mission actually needs. This creates two problems. It limits competition in ways that may not survive legal review, and it ensures that the selected solution may not actually fit the environment once the real requirements become clear during testing or assessment.

Failing to address bidirectional or multi-directional transfer requirements is another common gap. Programs often document their primary transfer direction thoroughly and treat the reverse direction or any lateral transfers as an afterthought. In a cross domain environment, each transfer direction is a separate risk surface and may require separate filter configurations, separate authorization conditions, and separate operational procedures. A requirements document that addresses only one direction when the mission needs more than one will produce a solution that needs to be modified almost immediately after deployment.

Assuming that an existing authorization from another program is transferable is a risk that shows up frequently in programs trying to move quickly. A cross domain solution that is authorized in one environment is not automatically authorized in a different environment, even if the security classification levels appear similar. The network ownership, the data types, the mission context, and the AO are all factors that may differ and that will require a fresh authorization effort. Requirements documents that assume inherited authority without verifying it create program risk that surfaces at the worst possible time.

Underestimating the time required for requirements development is a planning failure that creates cascade effects throughout the acquisition timeline. Programs that allocate two weeks for requirements development and then discover that the use case documentation alone takes six weeks of stakeholder coordination are programs that either compress the quality of their requirements or delay the acquisition. Neither outcome is acceptable for a mission-critical capability. Requirements development for a cross domain acquisition typically takes longer than programs expect, and the schedule should reflect that reality.

Not defining test and acceptance criteria as part of the requirements phase is a mistake that creates evaluation problems later. If the requirements document does not specify how each requirement will be verified, the evaluation team and eventually the assessor will need to define verification methods independently, which can produce inconsistent results and disputes about whether a solution actually meets requirements. Verification methods should be defined alongside each requirement during the planning phase, not improvised during testing.

Recommended Federal Approach

Programs that consistently produce useful cross domain requirements documents share a few structural characteristics. They begin requirements development much earlier than programs that struggle, typically before any acquisition documents are drafted and often before a formal program office exists. They bring together the right stakeholders from the beginning rather than adding them later. And they treat the requirements phase as a technical and analytical activity rather than a documentation formality.

The core planning team for cross domain requirements development should include the ISSO, the ISSM, the enterprise or solution architect, a network engineer familiar with both network environments, a representative from the operational mission team who can speak to actual use patterns, and a designated liaison to the AO. This is not a large team, but it covers the critical perspectives. Missing any one of these perspectives in the planning phase means that perspective will be represented later, during assessment or authorization, where changes are significantly more expensive.

The planning team should work through each use case collaboratively, not in parallel silos. The mission representative describes what the operation needs. The architect translates that into data flows. The network engineer identifies where those flows intersect the security boundary. The ISSO identifies what security controls apply to each flow. The ISSM validates that the combination of requirements is consistent with the authorization environment. That iterative conversation produces requirements that are technically accurate, operationally grounded, and security-compliant simultaneously.

Requirements should be reviewed against the relevant approved product list before the acquisition package is finalized. If no product on the approved list can satisfy a specific requirement, the program needs to know that before solicitation, not after evaluation. The review may reveal that a requirement needs to be adjusted to reflect what is technically achievable within the authorization constraints, or it may reveal that an approved product list exception or waiver process needs to be initiated. Both outcomes are manageable if discovered early. Neither is manageable if discovered after a contract has been awarded.

The requirements package should be reviewed for consistency across all planning documents before any external release. Use case documentation should align with data flow diagrams. Data flow diagrams should align with network architecture documentation. Security requirements should reflect the constraints documented in the AO engagement record. Operational requirements should be consistent with the concept of operations. Inconsistencies between documents are a signal that the planning team has not fully resolved a design question, and those questions are far better resolved in the planning phase than during a competitive evaluation or a security assessment.

Programs that invest the time and discipline to build complete, consistent, stakeholder-validated cross domain requirements before acquisition generally reach operational capability faster than programs that do not. The upfront investment in requirements quality pays dividends at every subsequent phase of the acquisition, the assessment, the authorization, and the sustainment. For programs where the cross domain capability is genuinely mission-critical, that investment is not optional. It is the foundation on which everything else depends.

For programs still building their understanding of the cross domain space, the Anchor Defense resources library provides additional planning and technical guidance relevant to federal cross domain environments.