Create and Assess Certification and Accreditation Strategies

Definition: Certification is the comprehensive evaluation and validation of a[n]...information system (IS) to establish the degree to which it complies with assigned information assurance (IA) controls based on standardized procedures. An accreditation decision is a formal statement by a designated accrediting authority (DAA) regarding acceptance of the risk associated with operating a[n]...IS and [is] expressed as an authorization to operate (ATO), interim ATO (IATO), interim authorization to test (IATT), or denial of ATO (DATO) [1].

Keywords: accreditation, certification, DIACAP

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to understand the principles of certification and accreditation (C&A), how a government development organization initiates the C&A process, and how the government sponsor maintains accreditation status following product delivery. They are also expected to understand information assurance (IA) and C&A requirements and processes so they can advise when the government or the contractor is not complying with the letter or intent of department or agency policies and processes. MITRE systems engineers are expected to understand how systems engineering decisions may impact the IA posture of a system.


This article is intended to provide general guidance on C&A of all government systems. It follows the Department of Defense (DoD) C&A process and is directly applicable to DoD systems. C&A processes for other U.S. government systems are similar in their essentials but otherwise may vary. In the latter case, the guidance presented here should serve as a general reference for the conduct of C&A activities. Non-DoD department or agency guidance should always take precedence for C&A of their systems.

Certification and Accreditation Process Overview

C&A processes applied to federal and DoD systems are similar. These similarities include use of a common set of functional roles as follows:



Information Owner

An official with statutory or operational authority for specified information and responsibility for establishing the controls for its generation, collection, processing, dissemination, and disposal.

Information System Owner

Individual, group, or organization responsible for ensuring the system is deployed and operated according to the agreed-on security requirements.

Certifying Authority/Agent (CA)

Individual, group, or organization responsible for conducting a security certification, or comprehensive assessment of the management, operational, and technical security controls in an information system.

Designated Accrediting Authority (DAA) or Authorizing Official

An official with the authority to formally assume responsibility for operating a system at an acceptable level of risk.

The following generic C&A process overview is based on the functional roles described above.

  1. The information owner establishes data sensitivity and security protection requirements.
  2. The information system owner implements technical, administrative, and operational security controls in accordance with security protection requirements provided by the information owner.
  3. The CA evaluates the security controls incorporated by the system and makes a recommendation to the DAA on whether the system satisfies its security requirements.
  4. The DAA assesses the residual security risk, based on the CA's recommendation, and makes an accreditation decision.
  5. The information system owner operates the accredited system, which must undergo periodic review and/or re-accreditation.

DoD Information Assurance Certification and Accreditation Process (DIACAP) [2, 3]

DIACAP is the C&A process applied to systems that store or process DoD information. It is defined in DoD Instruction 8510.01 as the "process to manage the implementation of IA capabilities and services and provide visibility of accreditation decisions regarding the operation of DoD information systems (IS), including core enterprise services and Web services–based software systems and applications." [1]

In supporting C&A of a system, MITRE should help the program manager (PM) assemble the DIACAP team, identify requirements, design solutions, implement the system, and integrate testing. The entire DIACAP team should be assembled at program inception to determine the IA Strategy, to agree on the mission assurance category (MAC) and confidentiality level, negotiate a baseline set of IA controls, and assign responsibilities. If there is no team review of system design for compliance with IA requirements, then testing of IA and functional requirements, which sometimes can conflict, will likely not be integrated. It is important that the DIACAP team be assembled to resolve discrepancies throughout the acquisition life cycle; without that cooperation, it is more likely the PM or engineers will make unilateral decisions the DAA may not be able to accept. To help ensure a successful positive C&A outcome, MITRE, often acting as "lead integrator" for the activity, should at the outset reach back to staff members who support the CA and DAA to ensure coordination and agreement regarding the scope of the C&A process.

Process Artifacts

Execution of the DIACAP produces a number of engineering artifacts that are summarized in the table below.



System Information Profile (SIP)

Information to register about the system being developed.

DIACAP Implementation Plan (DIP)

Enumerates, assigns, and tracks the status of IA controls being implemented.

DIACAP Scorecard

Records the results of test procedures/protocols used to validate implemented IA controls.

Plan of Action & Milestones (POA&M)

Identifies tasks or workarounds to remediate identified vulnerabilities.

Supporting Certification Documents

A compilation of IA controls validation artifacts provided to the CA.

Interim Approval to Test (IATT)

An accreditation decision is a special case for authorizing testing in an operational information environment or with live data for a specified time period.

Interim Approval to Operate (IATO)

An accreditation decision intended to manage IA security weaknesses while allowing system operation for up to 180 days, with consecutive IATOs totaling no more than 360 days.

Denial of Approval to Operate (DATO)

An accreditation decision that the system should not operate because the IA design, IA controls implementation or other security is inadequate and there are no compelling reasons to allow system operation.

Approval to Operate (ATO)

An accreditation decision for a system to process, store, or transmit information for up to three years; indicates a system has adequately implemented all assigned IA controls and residual risk is acceptable.

These artifact documents, together with all other documents resulting from the DIACAP process, are typically produced by the program office and/or the acquisition team. When a contractor produces a DIACAP document, it is reviewed and approved by the program office, often with a MITRE systems engineer involved.

Data Sensitivity and Mission Assurance Category

Each DoD system can be characterized by two pieces of information: the confidentiality level of the data that it processes and its MAC. These characteristics drive the selection of IA controls that the system must implement and the level of robustness (i.e., strength of mechanism) required.

The confidentiality level of a system is based on the highest classification or sensitivity of information stored and processed by the system. The confidentiality level is expressed in three categories: public, sensitive, and classified. More stringent authentication, access control, and auditing requirements apply to systems that process classified data than to systems that process sensitive data, while systems that process public data enforce minimal authentication, access control, or auditing requirements.

As described in DoD Instruction 8500.2, p 22, the MAC assesses the value of the system "relative to the achievement of DoD goals and objectives, particularly the warfighters' combat mission [3]." For systems designated as MAC I systems, loss of integrity or availability would result in immediate and sustained loss of mission effectiveness and cannot be tolerated. MAC II systems also have stringent data integrity requirements but may be unavailable for short periods of time without impacting mission effectiveness. With MAC III systems, the loss of data integrity and/or availability has no significant impact on mission effectiveness or operational readiness.

Information Assurance Controls

Information assurance controls used in DIACAP are detailed in DoD Instruction 8500.2 [3]. These safeguards are grouped into IA baselines, where the selection of an IA baseline is governed by the confidentiality level and MAC of the system. The following table specifies the number of IA controls that a system must satisfy as a function of the sensitivity and MAC level of that system.

















These numbers reflect the upper bound on the number of IA controls; in reality, many of the IA controls in a given IA baseline may not apply or may be inherited from an external, interconnected system. It should also be noted that while the number of IA controls required for MAC I and MAC II are the same for a given sensitivity level, the level of effort to satisfy those controls is often significantly higher for MAC I systems, where system availability requirements are considerably more stringent.

If IA requirements are not identified early in the acquisition/development process at the time functional requirements are identified, IA requirements cannot be built into the system and tested along with functional requirements. Although inappropriate, C&A is often performed after the system has been built; therefore, when IA controls validation is performed and the C&A documentation is presented to the CA and/or DAA, missing IA requirements may be identified far too late in the acquisition lifecycle. It is much more costly to modify a system to comply with IA requirements after it has been built than it is to build in IA up front.


A number of IA controls specify system robustness, which DoD Instruction 8500.2 defines as "the strength of mechanism and assurance properties of an IA solution." IA robustness requirements are expressed by IA controls as basic, medium, or high, and depend on the MAC and sensitivity level of the system and the threat environment in which the system will be deployed.

Commercial off-the-shelf (COTS) IA products or IA-enabled products selected for use in a system must satisfy IA robustness requirements established for that system. The robustness of COTS IA products are evaluated through the National Information Assurance Partnership (NIAP) [4]. An NIAP evaluation assigns an evaluated assurance level (EAL) rating to each product as a means for selecting IA products for use in system acquisition or development programs. The following table summarizes the IA characteristics of each robustness level and associated product EAL ranges.


Robustness Level




General Description

Commercial-grade best practice

High-end commercial-grade

High assurance design

Access Control

Authenticated access control

Strong (e.g., PKI-based) authenticated access control

NSA-endorsed access control and key management capabilities

Key Management

NIST-approved key management

NSA-approved key management


NIST FIPS-validated cryptography

NIST FIPS-validated cryptography

NSA-certified cryptography

Protection Profiles

Assurance properties consistent with NSA-endorsed basic robustness protection profiles

Assurance properties consistent with NSA-endorsed medium robustness protection profiles

Assurance properties consistent with NSA-endorsed high robustness protection profiles, where available

Evaluated Assurance Level (EAL)




Common Problems, Pitfalls, and Conundrums

IA, C&A, and security in general are not viewed as fundamental requirements and are often traded off when program funding is limited or cut (IA is not funded as a separate line item in the budget). PMs and engineers often don't realize that IA requirements are critical to the functionality of a system; IA ensures the appropriate amount of confidentiality, integrity, and availability are built in—something the warfighter demands.

Developmental testing (DT) is often performed in a vacuum. IA controls are not identified early on; therefore, the IA testing cannot be integrated into the DT. DT is planned and performed without consideration of the Operational Test & Evaluation (OT&E) certification requirement. Deficiencies are identified in OT&E that should have been caught in DT and fixed.

Once an ATO is issued, the tendency is to place the C&A package on the shelf for three years until the next accreditation is needed. If the system is not monitored constantly, with new vulnerabilities mitigated as they are discovered and as threats become increasingly more advanced, the IA posture of the system quickly degrades.

Best Practices

Employ information systems security engineering (ISSE) and reference the IA Technical Framework. The intent is for ISSEs to work with SEs throughout the acquisition lifecycle to build IA into the system. This cooperative effort will yield functional capability that is also secure. The SE and ISSE effort will also yield documentation that can be used as evidence of compliance with assigned IA controls—no need to generate special documents just to satisfy the CA and DAA.

  • Don't wait until the system is completely built to begin testing the IA controls. As capability is developed, test it—integrate the DT with IA controls testing. Also, integrate the DT with OT&E. OT&E teams can reuse the results of DT, but perform their own analysis. The test and evaluation master plan should identify, integrate, and track all types of testing.

If the CA is not able to participate in the DIACAP team meetings, employ the agent of the certifying authority (ACA) (or Service equivalent). The ACAs were established to stand in for the CA and handle the day-to-day certification activities. The ACAs also perform hands-on validation of IA controls, not a desktop review as may be done at a headquarters level. The ACAs are trusted by the CA, and the CA can take a DIACAP scorecard at face value—the CA need not dig into the details of a C&A package, so staffing goes faster.

  • PMs (with the help of the SE, ISSE, and ACA) must build a realistic POA&M that, in conjunction with the DIACAP scorecard, accurately conveys the residual risk to the DAA. The PM must aggressively resolve weaknesses and constantly update the POA&M, submitting it quarterly to the DAA for review/acceptance.
  • Keep the system current, relevant, and secure with a robust incident response and vulnerability management program. Threats evolve and exploit new vulnerabilities, thereby increasing risk. Constantly monitor the system to identify changes (threats, vulnerabilities, operations, environment, etc.) that could impact the IA posture. Ensure the IA manager is a member of the configuration control board to review all changes impacting IA.

References & Resources

  1. DoDI 8510.01, November 28, 2007, "DoD Information Assurance Certification and Accreditation Process (DIACAP)."
  2. Information Assurance Certification and Accreditation Process (DIACAP).
  3. DoD Instruction 8500.2, February 2003, "Information Assurance (IA) Implementation."
  4. The NIAP Evaluated Products List.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team