DIACAP Activity #4 Maintain Authorization to Operate and Conduct Review

Maintain Situational AwarenessIncluded in the IA controls assigned to all DoD ISs are IA controls related to configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g., penetration testing). The IAM continuously monitors the system or information environment for security-relevant events and configuration changes that negatively impact IA posture and periodically assesses the quality of IA controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g., IG DoD, Government Accountability Office (GAO)), exercises, and operational evaluations. In addition the IAM may, independently or at the direction of the CA or DAA, schedule a revalidation of any or all IA controls at any time. Reference (a) requires revalidation of a select number of IA controls at least annually. (DoD 8510.01,

Knowing what is going on with the system is the job of the Information Assurance Manager (IAM). This can be delegated to the Information Assurance Officer (IAO) or the IAM and IAO may be the same person, but keep in mind that these permission require training, a technical and security certification (IAW DoD 8570).

Maintain IA Posture

Ensuring that there are no changes to the IA posture falls on the shoulders of the IAM.  This includes making sure that the establish baseline of the system has no signifigant changes.  Most patches (even involving security) will have a minimal impact on the system.  Applicable patches should always be tested before being put on a system.  Major patches are usually service packs that may actually change the IA posture.  The DIACAP Team should be involved with any major changes to the IA posture.  They will also decide which modifications, upgrades and additions should be considered changes to the IA posture of the system.  As a minimum, the Program Manager, IAM, subject matter experts (software/system security engineers) and information system owner/user representative should be appart of that decision. 

What will likely be considered a change to the IA Posture:

Adding IA products (firewalls, intrusion detection systems, ect)

Some internetworking devices such as Routers and Switches

New operating systems

Major upgrades to software or operating systems (not including support applications)

Newly discover major vulnerabilities

*Basically any major changes that will affect the security, supportability, usability, and interoperability of the system.  It is important to have who, what when and where of sustainability, new risks, and usability requirements in writing.  Information Assurance includes all these things, not just security.

What are usually not changes to the IA Posture: 

Most NOTAM/IAVAS/TCNOs (such as Office patches, browser upgrades, ect)

Re-positioning equipment within the office (as long as the IAM has readable documentation on the data connections)

Adding passive periferal devices such as stand-alone printers, scanners and new monitors (devices with connectivity to external sources such as faxes, share external network printers should go before the DIACAP Team)

Devices such as DVD, CD and hard drives with more capacity may not affect the IA Posture but it is best to have some formalized method of tracking upgrades to hardware  especially on mission systems as some changes could have some unpredictable affects

Annual FISMA Reviews

DIACAP includes the task of performing reviews annually on the system.  This is one of the key features of the Federal Information System Management Act of 2002.  What ever command or branch of the DoD you reside, your system has the potential of being audited annually to make sure it is in compliance with federal regulations.  The eMASS IT Portfolio management systems (EITDR, DITPR-DON, APMS) also has this feature intergrated into its key functions.  All data on each systems IA posture is collect annually.   This is done by the IAMs and/or the DIACAP Team.

Additionally, each system must be re-accredited every three years: Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.  DoD 8510.01,

From DoD 8510.01, DIACAP: DoD ISs with a current ATO that are found to be operating in an unacceptable IA posture through GAO audits, IG DoD audits, or other reviews or events such as an annual security review or compliance validation shall have the newly identified weakness added to an existing or newly created IT Security POA&M. If a newly discovered CAT I weakness on a DoD IS operating with an ATO cannot be corrected within 30 days, the system can only continue operation under the terms prescribed in subparagraph If a newly discovered CAT II weakness on a DoD IS operating with a current ATO cannot be corrected or satisfactorily mitigated within 90 days, the system can only continue operation under the terms prescribed in subparagraph Maintain IA Posture. The IAM may recommend changes or improvement to the implementation of assigned IA controls, the assignment of additional IA controls, or changes or improvements to the design of the IS itself. Perform Reviews. The IAM shall annually provide a written or DoD PKI-certified digitally signed statement to the DAA and the CA that indicates the results of the security review of all IA controls and the testing of selected IA controls as required by Reference (a). The review will either confirm the effectiveness of assigned IA controls and their implementation, or it will recommend: changes such as those described in subparagraph; a change in accreditation status (e.g., accreditation status is downgraded to IATO or DATO); or development of an IT Security POA&M. The CA and DAA shall review the IAM statement in light of mission and information environment indicators and determine a course of action that will be provided to the concerned CIO or SIAO for reporting requirements described in Reference (a). The date of the annual security review will be recorded in the SIP. A DAA may downgrade or revoke an accreditation decision at any time if risk conditions or concerns so warrant. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.

Register the System with DoD IA Component

Register the System with DoD IA Component

Each branch of the military has an IA component. Each of the US Armed Services have a division under their respective chief information officer’s responsible for all computers, communications and networks in a given military branch. These communications divisions will house the Information Assurance component responsible for the DIACAP tasks.

Table 1. DoD IA Components

DoD Branch Branch Communication & Information Service Branch IA Component
US Air Force Air Force Communication Agency (AFCA)http://public.afca.af.mil/ AFCA/EVAssessment and Validatorshttp://public.afca.af.mil/library/
US Army *Army NETCOM 9th Signal Corps http://www.netcom.army.mil/ Army NETCOM Information Assurance Office
Department of the Navy DON CIODON Information Management and Information Technology (IM/IT)http://www.doncio.navy.mil DON SIAOhttp://www.doncio.navy.mil/Main.aspx

*more on Army NETCOM

Its important to get registered as soon as possible, because the DIACAP process (as with any certification & accreditation process) can take well over from six months to accomplish.

Role of the IA Component

Within the DIACAP Team, the IA Component’s role will likely be the “Certifying Authority” which is responsible for the final validation of security controls. This role is powerful in that it will determine whether or not the system is certified. The designated accreditation authority (DAA) listens the the recommendation of the CA. If the CA validates, the DAA will accredit. Also, the DAA can actually be within the IA Component, depending on the Mission Assurance Category (MAC) level (ref: USAF IT Lean/SISSU guidelines, this may differ within Army & DON).

IA Component’s IT Portfolio

DoD IT portfolio management (DoDD 8115.01) requires that each of the branches report to the DoD the status of IT systems.  Each branches IA Component has a Enterprise Mission Assurance Support Service (eMASS).  You will likely be tasked with entering your system into that database.  This is what is essentially meant by register the system with the DoD IA Component.

More on DoD IT portfolio management & eMASS

USAF Enterprise Information Technology Data Repository (EITDR)

The EITDR is a database controlled and managed by AFCA/EV. It includes information on most UNCLASS USAF IT systems. All data is uploaded from the EITDR into the Department of Defense Information Technology Profile Registry (DITPR) to meet Federal Information System Management Act requirements.

The DIACAP process is only a small part of what the data collected in the EITDR. The system is used to keep track of new acquisitions, new major DoD mandate compliance, program management and system engineering documentation.

EITDR maintains the Security, Interoperability, Supportability, Sustainability and Usability (SISSU) of all applicable systems. This process lists all DIACAP IA Controls. Stakeholder’s in the DIACAP Process (DIACAP Team) must be selected in order to access the SISSU process.

In the EITDR SISSU Phases are broken into Define Need, Design, Build and Test and Sustain And Release.   The questions are put into the following disciplines: Security, Interoperability, Supportability/Sustainability and Usability.  The IA Component (AFCA/EVSS) is responsible for validating & approving the Security phase.  All the other disciplines Validators and Approvers are chosen by the agency registering the system.  

 The EITDR allows stakeholders to set milestones and put the system through each phase of the DIACAP process. It also allows the producer to automatically create POA&Ms, System Identification Profile, DIACAP Implementation Plan and DIACAP Scorecard.

DIACAP Activity #2 Implement and Validate Assigned IA Controls

**28 Sept 2011– DIACAP is being changed to the DoD Risk Management Framework. 8510.01 is being changed to reflect the NIST SP 800-37, with security controls matching that of the NIST SP 800-53. This information is being released on the DIACAP Knowledge Service**

This activity is marked by actually putting the IA Controls into action. This means not only coordinating with software and/or system developers and engineers, but testing the IA Controls once they have been implemented.

Execute the DIACAP Implementation Plan

Executing the DIACAP Implementation Plan is the most critical part of the DIACAP process because it focuses almost exclusively on the assigned security controls. Your system may very well get an authorization to operate but if it does not have the appropriate security controls it could be a detriment to an organization and anything its is attached to by being an enormous vulnerability that is easily hacked or, more likely, a wasteful product that is very difficult to support in the long term. If anything, it is more important to get the IA Controls implemented than it is to get the system approved although the process is such that you should not have one without the other.

IA Controls are not just about security but include what the Air Force has called SISSU which stands for security, interoperability, sustainability, supportability and usability. All these features are checked annually under the DIACAP (activity #4).

The time it takes to implement the system should factor in any additional time it might take to implement and test the IA Controls.

Resistance to the Implementation of IA Controls

Be prepared for panic and gnashing of teeth when you tell them what is needed. Implementing the security controls can be a challenge. The cost, time and energy it takes to accomplish all the IA Controls can be intimidating at first glance.

Some engineers, program managers and system owners will resist the implementation of IA Controls, particularly if it is a legacy system that has operated just fine for years without any security controls. When dealing with reluctant customers the best thing you can do is come to meetings armed with federal regulations, operating instructions and mandates that have been issued by the DoD and signed by generals. You should be familiar enough to fully inform the customer of the risks associated with being non-compliant. Make sure that they are informed about how visible the system is in the eMASS database. Many times system owners will completely ignore regulations until they are absolutely forced to comply and by then they don’t have funding or time to comply.

Methods of Implementing the IA Controls

The technicians and/or engineers who are actually developing the system and installing the IA Controls should know about the tools that will make their job much easier.

For Windows systems those implementing the IA Controls should know about the following:

For Unix/Linux Systems:

Implementing Windows IA Controls

The quickest way to implement IA Controls on Windows systems is to use automated methods first to find and implement as many technical security features as possible and use STIGS and security guides for the remaining security controls that should be implemented. On a mission system, it is important to know that some security controls may break some critical functions. Some security controls can be ignored, some can be mitigated, some can have waivers and others absolutely must be complied with in some way, shape or form.

Federal Standard Configuration Operating Systems (if applicable)
Windows based systems with connections to the Global Information Grid may need to use a Federal Standard Configuration OS. This disk has various names. The USAF calls this disk the Standard Desktop Configuration (SDC) and Standard Server Configuration (SSC) for servers. Some federal organizations have Federal Desktop Common Configuration (FDCC), the Navy has NMCI systems and Army has Gold Master systems. These are locked down versions of Windows XP or Vista systems (depending on the version) that are only supposed to be altered under specialized circumstances.

These standard configurations may pose as a serious technical issue for mission systems that are not standard. Sustainment/Supportability funding might also be an issue for mission systems as SDC is mostly designed for systems with basic computing needs in a base area networks that uses devices like Microsoft System Management Service (SMS) to conduct automated pushes from all systems on the network. Mission systems usually have to be tested separately in order make sure new upgrades and IAVA’s don’t negatively affect the mission. Your system may be able to attain a waiver for the standard configuration. This configuration may not be needed for Windows systems not connected to the GIG.


DISA has disk called the Gold Disk that can scan for Category 1, 2 and 3 vulnerabilities according the applicable Mission Assurance Level. It can also automatically fix these vulnerabilities for Windows NT/XP and Vista. This scan should also be run on the standard configuration systems. You’ll be surprise how many vulnerabilities will show up even on standard configurations such as USAF SDC.

The challenges with the Gold Disk include the following: 1) there may be false positives. For example, Gold Disk may tell you that the Guest account should be removed. But Guest account is a built-in feature in Windows so it can only be disabled. 2) Some Category 1’s and 2’s may not be fixable on mission systems (especially legacy systems). In which case, it may have to be marked as non-compliant in the appropriate IA Controls. 3) Not all vulnerability Categories match up with the IA Controls so some of it will be up to your discretion. Also, the Cat 1, 2, or 3 results might not be applicable to your system. For example, you may have Internet Explorer vulnerabilities that pop-up on a system that will not actually use port 80 or the web at all.

Gold Disk is automated but it still needs a fairly technical & security oriented person to interpret the data.

Implementing UNIX/LINUX IA Controls

Unlike Windows there is no standard configuration for any UNIX environment. Currently, there are no plans published to change this. UNIX does have an automated script called the Security Readiness Review (SRR). Running the script requires solid skills in the command line. SRR picks up a lot of false positives so the technician/engineer running the script really needs to know what is running on the system and what does not need to be running. UNIX knowledge is really a must to use the SRR effectively.

The UNIX SRR Scripts are supported on the following platforms and versions:
Solaris 2.5.1 through Solaris 10; HP-UX 11.0, HP-UX 11.11; Red Hat Enterprise Linux 3 and 4; and AIX 4.3. – http://iase.disa.mil/stigs/SRR/index.html

STIGS and Security Guides

IA Control ECSC-1, Security Configuration Compliance directs the use of security guides and STIGS. DISA and the National Security Agency have created lots of security guides for Windows and accompanying applications. Implementation of these guides will satisfy many of the other IA Controls.


IA Controls

The IA Controls will likely be most of the work you do on any system. Even if you have a MAC III, Public, there are a lot of them. They require everything from developing and/or checking documentation, installing security features, ensuring proper network configurations to checking personnel and physical security at each site. The DIACAP Knowledge Service has several templates detailing each group of IA Controls according to Mission Assurance Levels.

Continuity – COxx – IA Control
The COxx series of the IA Controls deal with the continuity of the system. Developing a comprehensive continuity, disaster recovery, emergency management plan for the system will satisfy many of the COxx IA Controls. Your division, squadron, flight or company will usually have some sort of emergency management plans and disaster recovery instructions you can use. The old DITSCAP System Security Authorization Agreement had Appendix L, Contingency Plan. Many of the requested documents and process likely already exist so it maybe a matter of just finding them or re-packaging them.

Security Design and Configuration – DCXX – IA Control
The DCxx series deals with designing and maintaining a secure baseline. Dealing with these IA Controls will require and intimate knowledge of the systems software, hardware, and network configuration. If you don’t know the configuration of the system you should have a highly knowledgeable technician or engineer on hand who does. You will need to know the DoD policy to understand what is fully required or if the control is even applicable. Network and computer security policies such as AFI-33-202 for the USAF will be a good help. Systems that have been developed outside of the DoD and US services policies will have a real hard time with these IA Controls.

Enclave Computing Environments – EVxx – IA Controls
Enclave computing environments are IA Controls that deal with security features within the local area network or enclave. It will help to have some understanding of network security because some of the IA Controls address things like VPN and Remote Authentication.

Identification & Authentication – IAxx – IA Controls
Identification & Authentication address specific issues that deal with logon and passwords.

Physical & Environment – PExx – IA Controls
Physical & Environmental IA Controls deal with physical security of the sites, safety issues and environmental controls such as humidity systems.

Personnel – PRxx – IA Controls
These IA Controls deal with the training and access of each personnel with direct contact with the system.

Vulnerability and Incident Management – Vixx – IA Controls
The issues in these few IA Controls maybe addressed in the contingency plan. Elements within DITSCAP System Security Authorization Agreement had Appendix K, Incident Response may also be used for these IA Controls.

POA&M: When Systems Can Not be Fix

Some legacy systems can not comply with applicable IA Controls without spending millions of dollars that the program office and/or system owners don’t currently have. In these cases it’s important to have a “get well plan”. The document is called a Plan of Action & Milestone (POA&M). The POA&M details what IA Controls have not been met, when they will and how. The EITDR eMASS system can automatically create a POA&M document once all the IA Controls have been entered, Validated and Approved (others eMASS systems might be able to do this as well).

Conduct Validation Activities

Validation includes Certification Test & Evaluation (CT&E) and Security Test & Evaluation (ST&E). Certification Test & Evaluation is completed on a system on which IA Controls have been applied in a test environment. The CT&E is conducted to make sure all the IA Controls have been applied on a functional system. Once has been proven to work in a testing environment with all the applicable technical IA Controls applied the ST&E can be completed with a system in an operational environment.

Techniques used in the CT&E and ST&E may include Gold Disk Scan, SRR (UNIX), penetration testing (black box, white box, gray box), network vulnerability scan, source code scan, web application scan, or simply a manual check of each of the security controls using the security guides. During and ST&E on the site it is also helpful to make sure there is proper contingency plans, physical & operational security.

DIACAP Activity #1 Initiate and Plan Certification & Accreditation

Initiating the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) starts with a lot of “setting up shop”. Registering with a DoD component, forming the IA Team and assigning IA controls (also known as IA requirements and security controls) can be a lot of work, but the more of these tasks you complete, the easier the rest of the process will be.

Register the System with DoD IA Component

Each branch of the military has an IA component. Each of the US Armed Services have a division under their respective chief information officer’s responsible for all computers, communications and networks in a given military branch. These communications divisions will house the Information Assurance component responsible for the DIACAP tasks.

Table 1. DoD IA Components

DoD Branch Branch Communication & Information Service Branch IA Component
US Air Force Air Force Communication Agency (AFCA)http://public.afca.af.mil/ AFCA/EVAssessment and Validatorshttp://public.afca.af.mil/library/
US Army *Army NETCOM 9th Signal Corps http://www.netcom.army.mil/ Army NETCOM Information Assurance Office
Department of the Navy DON CIODON Information Management and Information Technology (IM/IT)http://www.doncio.navy.mil DON SIAOhttp://www.doncio.navy.mil/Main.aspx

*more on Army NETCOM

More on Registering with your IA Component

Once you’ve made contact with your system’s IA Component you may be asked to identify the players in your DIACAP Team. The DIACAP Team roles will consist of a Designated Approval Authority (DAA), Program Manager (PM), Certifying Authority (CA), User Rep, Information Assurance Manager and others. You will also need to identify other important players such as the Lead Engineer.

More on DIACAP Team Roles.

Get an Enterprise Mission Assurance Support Service (eMASS) account

The Enterprise Mission Assurance Support Service (eMASS) is a generic name for specific automated databases that are used to manage the DIACAP. Each branch has a different automated database (Fig 1). The USAF has the EITDR, The Navy has the DITPR-DON, and the Army has the APMS. Each of these databases satisfies DoD IT portfolio management, certification and IT reporting directives addressed in DoD Directive 8115.01, signed October 10, 2005.

Fig 1, DoD IT Portfolio Management System

eMASS IT Portfolio Management System

More on the eMASS systems.

Assign IA Controls

Information Assurance Controls are also known as Information Assurance requirements and security controls. IA Controls are assigned according to a system’s Mission Assurance Category (MAC) and Confidentiality Levels (Fig 2.) defined in DoDI 8500.2. The DIACAP Knowledge Service has Excel spread sheets breaking down each of the IA Controls.

Fig. 2, Mission Assurance Category & Confidentiality Levels

Mission Assurance Category (MAC) Confidentiality Levels

Some of the IA Controls require system security engineering interpretation because no system is alike. Some IA Controls will not apply while other will apply only under certain circumstances and that is where knowledgeable system & system security engineer comes in.



DoDI 8500.2, Enclosure 4

Initiate DIACAP Implementation Plan

With the proper MAC/CL level applied, the system security specialist/engineer and/or technician should have a good idea what IA Controls apply to a given system. The next step is to begin the DIACAP Implementation Plan.

The DIACAP Knowledge Service has a thorough break down of each of the IA Controls and how to accomplish and validate them. Once complete, your system’s DIACAP Implementation Plan should identify each of the applicable IA Controls, whether the system is compliant or not and when it will be compliant with those particular IA Controls.

Initiation of the DIACAP Plan means you are consulting developers and or Program Managers on the IA Controls that will affect the system. Both new systems, and existing legacy systems will require some sort of documentation whether a simple spreadsheet, or Word document detailing who, what, when and where of each IA Control feature applied to the system. The DIACAP Knowledge Service has a sample DIACAP Implementation Plan spread sheet that thoroughly details all the above requirements. It can be downloaded and tailored easily to your specific systems needs.

Once registered, the eMASS (EITDR, DITPR-DON, and APFM) system will require that you upload your completed DIACAP Implementation Plan (which is a bit of a paradox because the EITDR can actually create a DIACAP package once certain data is uploaded, validated and approved. EITDR will also require that the IA Controls be addressed and validated individually and subsequently Reviewed, Validated and Approved by system stakeholders.

Deliverables for Activity #1:DIACAP System Identification Profile (SIP)

DIACAP Implementation Plan

USAF SISSU Stakeholder’s List (Air Force)


DoD Regulation 5200.1-R , “DoD Information Security Program,” January 1997

DoDD 8115.01, “Information Technology Portfolio Management”, dated October 10, 2005

DoDD 8500.01E, “Information Assurance (IA),” dated April 23, 2007

DoD 8510.1-M, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Application Document”, dated July 31, 2000

DoDI 8551.1, “Ports, Protocols, and Services Management (PPSM) Release 6.9,” dated September, 2007

DoDD 8570.1, “Information Assurance Training, Certification, and Workforce Management,” dated August 15, 2004

DoDI 8570.1-M “Information Assurance Workforce Improvement Program,” dated December 19, 2005

Deputy Secretary of Defense Memorandum, “Information Technology Portfolio Management,” March 22, 2004

Federal Information Security Management Act (FISMA) (2002)

Information Assurance Support Environment (IASE)


DIACAP Team. Comprised of the individuals responsible for implementing the DIACAP for a specific DoD IS.  At a minimum the DIACAP Team includes the DAA, the CA, the DoD IS program manager (PM) or system manager (SM), the DoD IS IA manager (IAM), IA officer (IAO), and a user representative (UR) or their representatives. (DoDI 8510.01, E2.25)

*update: DIACAP is DoD Risk Management Framework (2014)

Designated Accrediting Authority (DAA). The official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. This term is synonymous with designated approving authority and delegated accrediting authority. (Reference (d) leads with the term designated approving authority, which was favored at the time of publication.). (DoDI 8510.01, E2.19) *DAA is Authorization Officer (2014)


Program Manager or System Manager (PM or SM). For the purpose of this Instruction, the individual with responsibility for and authority to accomplish program or system objectives for development, production, and sustainment to meet the user’s operational needs. (DoDI 8510.01, E2.50)

Certifying Authority (CA). The senior official having the authority and responsibility for the certification of ISs governed by a DoD Component IA program. (DoDI 8510.01, E2.12)

Certifying Authority Representative. An official appointed by and acting on behalf of the CA (DoDI 8510.01, E2.13).

IA Manager (IAM). The individual responsible for the information assurance program of a DoD information system or organization. While the term IAM is favored within the Department of Defense, it may be used interchangeably with the IA title Information Systems Security Manager (ISSM). (DoDI 8500.2, E2.1.27). Requirements: Demonstrate Need to know DoDD 8500.1 para: 4.8, US Citizen 8500.2 para: 5.8.3. must fit DoD 8570 applicable certifications.

IA Officer (IAO). An individual responsible to the IAM for ensuring that the appropriate operational IA posture is maintained for a DoD information system or organization. While the term IAO is favored within the Department of Defense, it may be used interchangeably with other IA titles (e.g., Information Systems Security Officer, Information Systems Security Custodian, Network Security Officer, or Terminal Area Security Officer). (DoDI 8500.2, E2.1.28)

Requirements: Demonstrate Need to know DoDD 8500.1 para: 4.8, can be foreign with DAA approval 8500.2 E3.T1 must fit DoD 8570 applicable certifications.

Other Roles:

E2.54. Senior Information Assurance Officer (SIAO). The official responsible for directing an organization’s IA program on behalf of the organization’s chief information officer.

The entire DIACAP process has many player involved with give the system a high level of visibility and decentralized responsibility.

Air Force Roles:

The Air Force DAA is AFNETOPS/CC (Gen. Elders, cira 2008). AFCA/CC serves as the DAA Representative (AFPD 33-2, para 5.9.6). The Air Force uses the DAA as the PAA. AFCA/EVSS acts as the Certifying Authority for the Security discipline of the SISSU process. Ref: AF 33-2, AFI 33-210

Lt. Gen. Michael W. Peterson is USAF Chief of Warfighting Integration and Chief Information Officer

Navy Roles:

Commander Naval Network Warfare Command (COMNETWARCOM).

CO designates, in writing, an Information Assurance Manager (IAM) who serves as POC for all command IA issues and implements command’s IA program. CO also designates, in writing Information Assurance Officer(s) to implement and maintain command’s network security requirements

Ref: SECNAV M-5510.30, Chapter 2

SECNAV M-5510.36, Chapter 2, 6, and 12

SECNAV M-5239.1, DON Information Assurance Program

Army Roles:The Director, Enterprise Systems Technology Activity (ESTA) is the DAA.

Ref: AR 25-2

*These roles are different for guard and reserve units


1 2