The CDS Authorization process for Point-to-Point is comprised of four phases: Phase 1 - Validation, Prioritization, and Requirements Analysis; Phase 2 - Solution Development and Risk Assessment; Phase 3 - Security Engineering and Risk Assessment; and Phase 4 - Annual Risk Review. The following diagram presents a graphical depiction of the CDS process.

Click image to enlarge map.

 

Figure 18 CDS Connection Process

Phase 1 CDS Authorization Process: Point-to-Point Solution

Validation, Prioritization and Requirements Analysis

Phase 1 of the CDS process consists of six specific actions. Any exceptions to the CDS process must be coordinated with your CC/S/A representatives and Cross Domain Technical Advisory Board (CDTAB) chair. The first three actions must be completed in 45 days.

1. The CDS Partner must coordinate with the CC/S/A Cross Domain Solutions Element (CDSE) representatives to determine and document the information transfer and mission requirements. These requirements must be documented in the Cross Domain Appendix (CDA).
   
   NOTE: All COCOMs must utilize the CDSE represented by their supporting agency as referenced in DoDD 5100.3, Support of the Headquarters of Combatant and Subordinate Joint Commands, 15 November 1999.
   
   NOTE: All COCOMs must also work with their CDSE to initiate a review of their mission requirements by DISA (CDES) to determine if DISA CDES can fulfill the technical requirements of their mission. This process must be completed prior to presenting the request to the Community Jury in step 5. If it is found that CDES can fulfill the mission requirements then the Community Jury may direct the COCOM to utilize CDES to perform their mission. In this case the COCOM will move to Phase 2 of the Enterprise Solution Process after ticketing approval of the Community Jury.
2. DoD Partner's CDSE obtains access to the SGS (https://giap.disa.smil.mil) through the CAO and opens a new CDS request filling out all required database fields. The DoD Partner must also submit to their CDSE a Phase 1 CDA and a validation memo signed by their respective DAA. Their CDSE will upload these documents to the SGS request. 
3. The DoD Partner's respective CDSE validates and prioritizes the Request and submits a CDSAP agenda request to the CDTAB Secretariat.
   
   NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
4. The request is brought before the CDSAP to determine if a CDS is required to meet the Partner's requirement and if the proposed solution versus an alternative solution is recommended. This determination is then presented to the Community Jury in Step 5.
5. The CDS Request and CDSAP comments are brought before the Community Jury (a function of the DSAWG) to obtain approval for ticketing and engineering.
6. If approved by the Community Jury and the CDS is going to be implemented as a point-to-point solution, the CDS team will assign a CDS ticket number and the CDS is transitioned into Phase 2. If approved by the Community Jury and DISA CDES is going to meet the requirement, the request number will be closed and the requirement will be met under a CDES ticket number (see K.3).

 

Phase 2 CDS Authorization Process: Point-to-Point Solution

Security Engineering and Risk Assessment

1. The Partner works with their respective CDSE to engineer the CDS, and to complete and upload the following to the SGS: 1) Phase 2 CDA, 2) a Security, Test, and Evaluation (ST&E) Plan; and 3) ST&E Procedures. The Partner submits these documents to their CDSE who will upload them to SGS. 
   
   NOTE: The Partner should contact their respective CDSE if they have questions or need assistance with completing the required content in the referenced documents.
2. The respective CDSE reviews and prioritizes the CDS ticket with NSA. The CDS Team will perform a grid connectivity threat (GCT) analysis based on the ticket priority submitted by the CDSE. It is the CDSE's CDTAB Representative's responsibility to complete the Transfer Processing Threat Report and to submit a request for an agenda to be presented to the Cross Domain Solutions Assessment Panel (CDSAP) or CDTAB.
   
   NOTE: Each CDSE must submit all requests for GCT ratings from the CDS Team no later than the first Monday of the month if they intend to bring the ticket before the CDTAB.
3. Draft risk analysis results are completed by NSA, the respective CDSE, the CDS Team, and DIA following the Risk Decision Authority Criteria (RDAC) criteria. These results must be uploaded to SGS.
4. The respective CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
   
   NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
5. At the CDTAB, the voting members will review the information provided from the Partner's CDA and the compiled risk rating then provide a vote of concur or non-concur with the risk rating.
6. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a CDSA for ST&E. If approved and all other enclave documentation has met standard requirements, the CDS team will issue a CDSA for ST&E and the CDS ticket transitions into Phase 3.
   
   NOTE: For a CDSA to be issued, the following items are required:

• Partner's Valid ATC for the enclave where CDS is operating
• DAA Signed CDA referencing CCSD by DAA (Phase 2 – IATC and Phase 3 – ATC) or enclave ATO referencing the CDS
• Topology referencing the specific ticket number of the CDS
• Signed CDA by DAA (Phase 2 – IATC and Phase 3 – ATC) or ATO signed by DAA. (For Non-DISN Connections)

 

Phase 3 CDS Authorization Process: Point-to-Point Solution

ST&E Risk Review and Authorization for Operational Use

1. Upon completion of the ST&E the Partner must submit the ST&E results and updated Phase 3 CDA to their CDSE for upload to SGS.
2. The respective CDSE reviews the ST&E results to verify no changes exist between the Draft Risk Analysis and the actual test results. The CDSE must notify the CAO of any changes prior to ticket submission as an agenda request or initiation of a Cross Domain Solution Authorization for operational use.
3. If, prior to Phase 2 approval, the DSAWG also granted approval for operational use, and the CDSE finds the ST&E result concur with the Draft Risk Analysis, the respective CDSE may request a CDSA from the CDS Team as per step 18. Otherwise, the respective CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
   
   NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
4. At the CDTAB, the voting members will review the information provided from the Partner's CDA and the compiled risk rating and provide a vote of concur or non-concur with the risk rating and comments.
5. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a one-year CDSA.
6. If approved by the DSAWG, and all other enclave documentation has met standard requirements, the CDS Team will issue a one-year CDSA. The CDS ticket transitions into Phase 4.
   
   NOTE: For a CDSA to be issued, the following items are required:

• Partner’s Valid ATC for the enclave where CDS is operating
• DAA Signed CDA referencing CCSD by DAA (Phase 2 – IATC and Phase 3 – ATC) or enclave ATO referencing the CDS
• Topology referencing the specific ticket number of the CDS.
• Signed CDA by DAA (Phase 2 – IATC and Phase 3 – ATC) or ATO signed by DAA. (For Non-DISN Connections) 

NOTE: The CDS device is marked operational in SGS upon the initial issuance of a CDSA by the CDS Team following a DSAWG approval. It remains operational until the CDTAB Secretariat receives evidence from the DAA through the Partner's respective CDSE that the device is non-operational.

 

Phase 4 CDS Authorization Process: Point-to-Point Solution

Annual Risk Review

CDS's will receive no more than a 1-year CDSA from the DSAWG. In order to receive approval for following years, the following requirements must be met.

1. Complete a satisfactory scan of the enclave by the CAO (or a POAM if unsatisfactory), submit a revalidation memo from the DAA stating that the CDS is still required and the CDS configuration has not changed, and provide notification to the CDSE of completion of the actions.  (see JTF GNO Communications Tasking Order (CTO) 07-09, Support for Remote Vulnerability Assessment and Compliance Monitoring Scans of SIPRNet Enclaves (Revised Guidance), 191640Z Jul 07, Secret https://www.cybercom.smil.mil/J3/orders/CTOs/CTO0709.doc  (SIPRNet) and DISN CPG paragraph 1.2. for scan requirements.)  

NOTE: The DAA is required to revalidate all CDS devices in enclaves containing CDS devices annually. The DAA revalidates operational and functional requirements, verifies the configuration described in the CDS documentation is correct, ensures and validates annual testing of CDS controls, operational requirements, configuration, and notifies the respective CDSE that this review has been conducted. This notification should be in the form of an annual revalidation letter and should be uploaded to SGS under the respective CDS ticket number.

1. The respective CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
   
   NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
2. At the CDTAB, the voting members will review the CDS Annual Review requirements, information provided extracted from the Partner's CDA and the previous risk rating, and provide a vote of concur or non-concur with the risk rating and comments.
3. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a 1-year CDSA.

If approved by the DSAWG, and all other enclave documentation has met standard requirements, the CDS Team will issue a 1-year CDSA. The CDS Ticket will remain in Phase IV.

NOTE: For a CDSA to be issued, the following items are required:

• Partner's Valid ATC for the enclave where CDS is operating
• DAA Signed CDA referencing CCSD by DAA (Phase 2 – IATC and Phase 3 – ATC) or enclave ATO referencing the CDS
• Topology referencing the specific ticket number of the CDS.
• Signed CDA by DAA (Phase 2 – IATC and Phase 3 – ATC) or ATO signed by DAA. (For Non-DISN Connections)

NOTE: Planned changes to the configuration of the CDS including patches and upgrades must be coordinated with the Partner's respective CDSE and entered into the SGS as Phase I requests. These requests must follow the normal CDS review process and be approved by the DSAWG prior to implementation.

NOTE: If for any reason it becomes necessary to discontinue use of a CDS, the CDSE must submit a closure request memo in order to stop tracking of the CDS ticket in SGS. The CDS analyst who performs the closure will upload the closure request to SGS under the ticket in question, and close the ticket with the comment "Closed per CDSE request".

The CDS Authorization process for Cross Domain Enterprise Services (CDES) is comprised of four phases:

• Phase 1 - Validation, Prioritization, and Requirements Analysis
• Phase 2 - Solution Development and Risk Assessment
• Phase 3 - Security Engineering and Risk Assessment
• Phase 4 - Annual Risk Review

 

The process is slightly different for a Partner request being added to a new CDES solution vice an existing CDES solution. If the request is going to be added to an existing CDES solution, they will enter the CDES process at Phase 2. If the request is going to be met by a new CDES solution, they will enter the CDES process at Phase 1 and essentially will be going through Phase 1 twice, since they already went through the same Phase 1 as a point-to-point solution.

 

Phase 1 CDS Authorization Process: CDES

Validation, Prioritization, and Requirements Analysis

Phase 1 of the CDS process consists of six specific actions. Any exceptions to the CDS process must be coordinated with your CC/S/A representatives and Cross Domain Technical Advisory Board (CDTAB) chair. The first three actions must be completed in 45 days. In order for CDES to go forward with a request to build a new CDES solution, they must come forward with an already approved Partner request that is awaiting implementation in the Enterprise. This is because DSAWG will not approve building a new solution if there is not a Partner requirement for that solution.

1. CDES must coordinate with the DISA Cross Domain Solutions Organization (CDSE) representatives to determine and document the information transfer and mission requirements based on a previously approved Partner request. These requirements must be documented on the Cross Domain Appendix (CDA).
2. CDES opens a new CDS request in the SGS filling out all required database fields, uploads a Phase 1 Cross Domain Appendix (CDA), and notifies their CDSE of completion of these requirements.
3. The Partner's respective CDSE validates and prioritizes the Request and submits a CDSAP agenda request to the CDTAB Secretariat.
   
   NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
4. The request is brought before the CDSAP to determine if a CDS is required to meet the Partner's requirement and if the proposed solution versus an alternative solution is recommended. This determination is then presented to the Community Jury in Step 5.
5. The CDES Request and CDSAP comments are brought before the Community Jury (a function of the DSAWG) to obtain approval for ticketing and engineering.
6. If approved by the Community Jury the CDS Team will assign a CDS Ticket Number and the CDES Request is transitioned into Phase II.

 

Phase 2 CDS Authorization Process: CDES

Security Engineering and Risk Assessment

NOTE: If the DoD Partner's request has already been approved by the Community Jury and is going to be added to preexisting CDES solution, the request will enter the CDES process at this phase (see 1.b).

1. New or Existing CDES:
2. New CDS: CDES works with DISA CDSE to engineer the CDS, complete, and upload the following to the SGS:
3. Phase 2 CDA
4. ST&E Plan
5. ST&E Procedures
   
   

   NOTE: CDES should contact DISA CDSE if they have questions or need assistance with completing the required content in the referenced documents. CDES notifies the CDSE when all requirements have been met.
6. Existing CDS: The DISA CDSE requests an updated ticket instance from the CDS Team. CDES works with DISA CDSE to engineer the CDS, complete, and upload the following to the SGS:
   
   

   NOTE: CDES should contact DISA CDSE if they have questions or need assistance with completing the required content in the referenced documents. CDES notifies the DISA CDSE when all requirements have been met.

7. Phase II CDA
8. ST&E Plan
9. ST&E Procedures
10. DISA CDSE reviews and prioritizes the CDS ticket with NSA and the CDS Team who completes the bulk of the draft risk analysis report.
    
    NOTE: Each CDSE must submit all requests for GCT ratings from the CDS Team no later than the first Monday of the month if they intend to bring the ticket before the CDTAB.
11. Draft Risk Analysis results are completed by NSA, the DISA CDSE, the CDS Team, and DIA following the Risk Decision Authority Criteria (RDAC) criteria. These results must be uploaded to SGS.
12. DISA CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
    
    NOTE: Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will NOT be accepted.
13. At the CDTAB the voting members will review the information provided from the Partner's CDA and the compiled risk rating and provide a vote of concur or non-concur with the risk rating.
14. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a CDSA for ST&E.
15. If approved and all other enclave documentation has met standard requirements, the CDS Team will issue a CDSA for ST&E and the CDS ticket transitions into Phase III.

 

Phase 3 CDS Authorization Process: CDES

ST&E Risk Review and Authorization for Operational Use

1. Upon completion of the ST&E CDES must upload the ST&E results and updated Phase III CDA to the SGS. CDES notifies the DISA CDSE of these actions.
2. The respective CDSE reviews the ST&E results to verify no changes exist between the Draft Risk Analysis and the actual test results. The CDSE must notify the CAO of any changes prior to ticket submission as an agenda request or initiation of a Cross Domain Solution Authorization for operational use.
3. If, in concurrence with Phase 2 approval, the DSAWG also granted approval for operational use, and the CDSE finds the ST&E result concur with the Draft Risk Analysis, the respective CDSE may request a CDSA from the CDS Team as per step 7. Otherwise, the respective CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
4. DISA CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
   
   NOTE: All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner.
5. At the CDTAB, the voting members will review the information provided from the CDES CDA and the compiled risk rating and provide a vote of concur or non-concur with the risk rating and comments.
6. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a 1-year CDSA.
7. If approved by the DSAWG, and all other enclave documentation has met standard requirements, the CDS Team will issue a 1-year CDSA. The CDS Ticket transitions into Phase IV.
   
   NOTE: For a CDSA to be issued, the following items are required:

• Partner's Valid ATC for the enclave where CDS is operating
• DAA Signed CDA referencing CCSD by DAA (Phase 2 – IATC and Phase 3 – ATC) or enclave ATO referencing the CDS
• Topology referencing the specific ticket number of the CDS.
• Signed CDA by DAA (Phase 2 – IATC and Phase 3 – ATC) or ATO signed by DAA. (For Non-DISN Connections)
  

NOTE: The CDS device is marked operational in SGS upon the initial issuance of a CDSA by the CDS Team following a DSAWG approval. It remains operational until the CDTAB Secretariat receives evidence from the DAA through the Partner's respective CDSE that the device is non-operational.

 

Phase 4 CDS Authorization Process: CDES

Annual Risk Review for CDES Solutions

CDS devices will receive no more than a one-year CDSA from the DSAWG. In order to receive additional operational approval, the following requirements must be met:

1. Completion of a satisfactory scan of the enclave by the CAO and all necessary revalidation memorandums (see note below).  Once these requirements have been completed the mission partner must notify the CDSE that the CDS device is ready for review by CDTAB.
   
   NOTE: All CDS devices require annual mission partner and enterprise DAA revalidation. The DAA owning the enclave where the CDS resides provides a revalidation memorandum stating that the configuration has not been changed since it was last approved and that it has been tested. The DAA of the hosting enclave cannot verify that the requirement still exists since they do not own the mission. Therefore each partner DAA on an enterprise CDS device will need to provide a revalidation memorandum stating they still need the channel/s to meet their mission needs. The mission statement must also be restated in each mission partner revalidation memorandum since some missions differ slightly over time. The responsible enterprise CDS service provider will manage the revalidation process for their respective enterprise guards by coordinating with the hosting enclave DAA and the mission partner DAAs to request the revalidation memorandums. The responsible enterprise CDS service provider will upload all revalidation memorandums in the SGS database under the respective ticket number.
2. DISA CDSE submits a CDTAB agenda request to the CDTAB Secretariat.
   
   NOTE: All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Agenda requests will not be accepted by the CDTAB Secretariat directly from the Partner.
3. At the CDTAB, the voting members will review the CDS Annual Review requirements, information provided extracted from the Partner's CDA and the previous risk rating, and provide a vote of concur or non-concur with the risk rating and comments.
4. The ticket will then be presented to the DSAWG with the CDTAB's risk rating and comments. The DSAWG will make a decision whether or not to approve a 1-year CDSA.
5. If approved by the DSAWG, and all other enclave documentation has met standard requirements, the CDS Team will issue a 1-year CDSA. The CDS Ticket will remain in Phase IV.
   
   NOTE: For a CDSA to be issued, the following items are required:

• Partner's Valid ATC for the enclave where CDS is operating
• DAA Signed CDA referencing CCSD by DAA (Phase 2 – IATC and Phase 3 – ATC) or enclave ATO referencing the CDS
• Topology referencing the specific ticket number of the CDS.
• Signed CDA by DAA (Phase 2 – IATC and Phase 3 – ATC) or ATO signed by DAA. (For Non-DISN Connections)

NOTE: Planned changes to the configuration of the CDS including patches and upgrades must be coordinated with the Partner's respective CDSE and entered into the SGS as Phase I requests. These requests must follow the normal CDS review process and be approved by the DSAWG prior to implementation.

NOTE: As the CDES approval process may open multiple Partner requests under one ticket, it is important to remember that each instantiation portion of a CDES ticket number represents an individual Partner Mission. Expiration of an individual instantiation of a CDES ticket should not be interpreted as the expiration of that guard, but instead the expiration of a Partner Mission. CDES should track these instantiations in order to ensure each Partner Mission is revalidated as its yearly approval approaches its expiration.

NOTE: If for any reason it becomes necessary to discontinue use of a CDS or a mission partner is no longer continuing their mission, the DISA CDSE must submit a closure request memo in order to stop tracking of the CDS ticket in SGS. The CDS analyst who performs the closure will upload the closure request to SGS under the ticket in question, and close the ticket with the comment "Closed per CDSE request".

 

Frequently Asked Questions

Q. Do I need to create a request for every CDS device/distribution console I intend to meet a specific requirement? What if it is a hot or cold spare or being used for load balancing?

A. A separate request/ticket is required for each CDS device/distribution console if the device is used as a hot spare or load balancing. A separate request is not needed for a cold spare but the cold spare must go through ST&E with the primary and evidence of the ST&E results must be uploaded under the SGS. In the event the cold spare is utilized, the CDSE and CDS Team must be notified and a new request must be opened.

Q. What is the significance of the three partitions of a CDS ticket number?

A. Once a Request (ex: R0001111) is approved at Community Jury, it is assigned a ticket number that is formatted in three partitions (ex: 1234-0001-001). The significance of these partitions is listed below:

1. First partition (1234-0001-001): The first partition represents the Partner requirement. If this is a new Partner requirement, the Request will receive a ticket number with a unique first partition; the second and third partitions will be 1.
2. Second partition (1234-0001-001): The second partition represents the instantiation of the CDS device. For example, if three CDS devices were needed for load balancing, the ticket numbers would be 1234-0001-001, 1234-0002-001, and 1234-0003-001. The configuration and Partner requirement is the same, but there are three devices meeting this requirement. These devices could be the same configuration at the same location or they could be the same configuration at three different locations.
3. Third partition (1234-0001-001): The third partition of the ticket number represents the iteration of the ticket. This number is usually created when a CDS Request is approved to change the configuration or upgrade a previous device. For CDES, this happens often due to the addition of new channels supporting new Partners. For example: If pre-existing ticket 1234-0001-001 were upgrading to the next version of RM, the newly assigned ticket number would be 1234-0001-002.
   

 

Q. What is the different between a CDSA and an ATC?

A. Once a DIACAP package is submitted, reviewed and accepted by the CAO an ATC for the CCSD is issued. The ATC contains the statement "This ATC does not authorize any Cross Domain Solutions, a Separate Cross Domain Solution Authorization Letter will be issued authorizing Cross Domains." A CDSA is issued after DSAWG approval of a CDS contingent upon a current ATC for the CCSD and the ATO, and Topology properly referencing the CDS ticket number.

NOTE: The CDSA expiration date will not exceed the ATC expiration date if the ATC expires prior to the DSAWG approval expiration. Once a new ATC is issued, another CDSA will be issued for the remainder of the DSAWG approval window.

Q. What is the difference between a point-to-point solution and a DISA Cross Domain Enterprise Solution? Am I required to use Enterprise Services?

A For a point-to-point solution, a Partner has a requirement to pass data across security domains, places a request, and purchases their own Cross Domain device to facilitate the information transfer. Cross Domain Enterprise Services (CDES) have systems that may be able to facilitate the Partner's information transfer requirement. One CDES CDS device could facilitate the transfer of multiple channels from multiple Partners. Partners are not required, but are strongly encouraged, to utilize DISA's CDES if their requirement can be met by a CDES Solution. To find out if your requirement could be met by DISA CDES, contact the DISA CDSE at cio-cdso2@disa.mil.

 

Points of Contact

All e-mail correspondence with the CDTAB Secretariat should to be sent to Disa.meade.ns.mbx.cdtab@mail.smil.mil.

CAO Cross Domain Solutions
CDS Process Questions	disa.meade.ns.mbx.cdtab@mail.mil (NIPRNet) or Disa.meade.ns.mbx.cdtab@mail.smil.mil (SIPRNet)
Updated Enclave Paperwork*	disa.meade.ns.mbx.cdtab@mail.mil  (NIPRNet) or Disa.meade.ns.mbx.cdtab@mail.smil.mil (SIPRNet)
Phone (Commercial)	301-225-2903
Phone (DSN)	312-375-2903
Website	http://disa.mil/connect

 

DIACAP paperwork with an ATO expiration date different from that reviewed upon issuance of your last ATC cannot be submitted to Disa.meade.ns.mbx.cdtab@mail.smil.mil. Please submit the complete DIACAP package to Disa.meade.ns.mbx.ccao@mail.smil.mil.

 

Additional Policy and Guidance Documents

CJCSI 6211. 02D	Defense Information Systems Network (DISN): Policy and Responsibilities, 24 January 2012
DISA Charter	Cross Domain Technical Advisory Board, 18 April 2010
RDAC 2.3, NSA	Risk Decision Authority Criteria
DoDD 5100.3	Support of the Headquarters of Combatant and Subordinate Joint Commands, 9 February 2011