<Glossary>
	<Section Letter="A">
		<Entry>
			 <Term>Accreditation Boundary</Term>
			 <Definition>1. (IA) - Identifies the information resources covered by an accreditation decision, as distinguished from separately accredited information resources that are interconnected or with which information is exchanged via messaging. (Synonymous with Security Perimeter) &#10;2. (IC) – For the purposes of identifying the Protection Level for confidentiality of a system to be accredited, the system has a conceptual boundary that extends to all intended users of the system, both directly and indirectly connected, who receive output from the system (DCID 6/3, 5 Jun 99)
Committee on National Security Systems Instruction No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006</Definition>
		</Entry>
		<Entry>
			 <Term>Accreditation Decision</Term>
			 <Definition>A formal statement by a designated accrediting authority (DAA) regarding acceptance of the risk associated with operating a DoD information system (IS) and expressed as an authorization to operate (ATO), interim ATO (IATO), interim authorization to test (IATT), or denial of ATO (DATO). The accreditation decision may be issued in hard copy with a traditional signature or issued electronically signed with a DoD public key infrastructure (PKI)-certified digital signature.</Definition>
		</Entry>
		<Entry>
			 <Term>Adequate Security</Term>
			 <Definition>Security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that information systems operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost-effective management, personnel, operational, and technical controls. (OMB Circular A-130)
Committee on National Security Systems Instruction No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006</Definition>
		</Entry>
		<Entry>
			 <Term>Artifacts</Term>
			 <Definition>System policies, documentation, plans, test procedures, test results, and other evidence that express or enforce the information assurance (IA) posture of the DoD IS, make up the certification and accreditation (C&A) information, and provide evidence of compliance with the assigned IA controls.</Definition>
		</Entry>
		<Entry>
			 <Term>Assigned IA Controls</Term>
			 <Definition>The set of IA controls that a given DoD IS must address to achieve an adequate IA posture. Consist of baseline IA controls plus any augmenting IA controls.</Definition>
		</Entry>
		<Entry>
			 <Term>Augmenting IA Controls</Term>
			 <Definition>IA controls that augment baseline IA controls to address special security needs or unique requirements (e.g., cross security domain solutions, health information portability, privacy, etc.) of the IS(s) to which they apply. Augmenting IA controls may originate from a mission area (MA), a DoD Component, a Community of Interest (COI), or a local system. Augmenting IA controls must neither contradict nor negate DoD baseline IA controls and must not degrade interoperability across the DoD Enterprise.</Definition>
		</Entry>
		<Entry>
			 <Term>Authorization Termination Date (ATD)</Term>
			 <Definition>The date assigned by the DAA that indicates when an ATO, IATO, or IATT expires.</Definition>
		</Entry>
		<Entry>
			 <Term>Authorization to Operate (ATO)</Term>
			 <Definition>Authorization granted by a DAA for a DoD IS to process, store, or transmit information. An ATO indicates a DoD IS has adequately implemented all assigned IA controls to the point where residual risk is acceptable to the DAA. ATOs may be issued for up to 3 years.</Definition>
		</Entry>
	</Section>
	<Section Letter="B">
		<Entry>
			 <Term>Baseline IA Controls</Term>
			 <Definition>The minimum set of IA controls that must be addressed to achieve adequate security. Baseline IA controls are prescribed by DoDI 8500.2 (Reference (d)) based on mission assurance category (MAC) and confidentiality level (CL).</Definition>
		</Entry>
	</Section>
	<Section Letter="C">
		<Entry>
			 <Term>Certification.</Term>
			 <Definition>For the purpose of this Instruction, a comprehensive evaluation and validation of a DoD IS to establish the degree to which it complies with assigned IA controls based on standardized procedures.</Definition>
		</Entry>
		<Entry>
			 <Term>Certification Determination.</Term>
			 <Definition>A CA’s determination of the degree to which a system complies with assigned IA controls based on validation results. It identifies and assesses the residual risk with operating a system and the costs to correct or mitigate IA security weaknesses as documented in the Information Technology (IT) Security Plan of Action and Milestones (POA&M). </Definition>
		</Entry>
		<Entry>
			 <Term>Certifying Authority (CA).</Term>
			 <Definition>The senior official having the authority and responsibility for the certification of ISs governed by a DoD Component IA program. </Definition>
		</Entry>
		<Entry>
			 <Term>Certifying Authority Representative.</Term>
			 <Definition>An official appointed by and acting on behalf of the CA. </Definition>
		</Entry>
		<Entry>
			 <Term>Communities of Interest (COIs).</Term>
			 <Definition>For the purpose of this Instruction, the inclusive term used to describe groups of individuals who share information relative to common goals, interests, missions, or business processes. </Definition>
		</Entry>
		<Entry>
			 <Term>Community Risk.</Term>
			 <Definition>Probability that a particular vulnerability will be exploited within an interacting population and adversely impact some members of that population.
DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002</Definition>
		</Entry>
		<Entry>
			 <Term>Confidentiality Level (CL).</Term>
			 <Definition>Applicable to DoD information systems, the confidentiality level is primarily used to establish acceptable access factors, such as requirements for individual security clearances or background investigations, access approvals, and need-to-know determinations; interconnection controls and approvals; and acceptable methods by which users may access the system (e.g., intranet, Internet, wireless). The Department of Defense has three defined confidentiality levels: classified, sensitive, and public.
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Core Enterprise Services (CESs).</Term>
			 <Definition>For the purpose of this Instruction, a set of common services intended to provide, enable, or improve access; enable information sharing; and enhance interoperability among Global Information Grid (GIG) entities. CESs enable service-oriented architectures and may include Web services. Examples of CESs include enterprise services management, messaging, discovery, mediation, collaboration, hosting, storage, IA/security, metadata services, and user assistance. </Definition>
		</Entry>
	</Section>
	<Section Letter="D">
		<Entry>
			 <Term>Denial of Authorization to Operate (DATO).</Term>
			 <Definition>A DAA decision that a DoD IS cannot operate because of an inadequate IA design, failure to adequately implement assigned IA controls, or other lack of adequate security. If the system is already operational, the operation of the system is halted. </Definition>
		</Entry>
		<Entry>
			 <Term>Designated Accrediting Authority (DAA).</Term>
			 <Definition>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.) </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Implementation Plan (DIP).</Term>
			 <Definition>Contains the IS’s assigned IA controls. The plan also includes the implementation status, responsible entities, resources, and the estimated completion date for each assigned IA control. The plan may reference applicable supporting implementation material and artifacts. </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Knowledge Service (KS).</Term>
			 <Definition>A Web-based repository of information and tools for implementing the DIACAP that is maintained through the DIACAP Technical Advisory Group (TAG). </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Package.</Term>
			 <Definition>The collection of documents or collection of data objects generated through DIACAP implementation for an IS. A DIACAP package is developed through implementing the activities of the DIACAP and maintained throughout a system’s life cycle. Information from the package is made available as needed to support an accreditation or other decision such as a connection approval. There are two types of DIACAP packages: &#10;The Comprehensive Package contains all of the information connected with the certification of the IS. It includes the System Identification Profile (SIP), the DIACAP Implementation Plan (DIP), the Supporting Certification Documentation, the DIACAP Scorecard, and the IT Security POA&amp;M, if required. &#10;The Executive Package contains the minimum information for an accreditation decision. It contains the SIP, the DIACAP Scorecard, and the IT Security POA&amp;M, if required. </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Scorecard.</Term>
			 <Definition>A summary report that succinctly conveys information on the IA posture of a DoD IS in a format that can be exchanged electronically. It shows the implementation status of a DoD IS’s assigned IA controls (i.e., compliant (C), non compliant (NC), or not applicable (NA)) as well as the C&A status. </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Technical Advisory Group (TAG).</Term>
			 <Definition>A formally chartered body established by Assistant Secretary of Defense for Networks and Information Integration/DoD Chief Information Officer to examine and address common C&A issues, including changes to the baseline IA controls, across the DoD Component IA programs, IA COIs, and other GIG entities. The DIACAP TAG also maintains configuration control and management of the DIACAP and all its supporting content on the DIACAP KS. </Definition>
		</Entry>
		<Entry>
			 <Term>DIACAP Team.</Term>
			 <Definition>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. </Definition>
		</Entry>
		<Entry>
			 <Term>DoD-Controlled IS.</Term>
			 <Definition>An IS that is established only for DoD purposes, dedicated to DoD processing, and is effectively under DoD configuration control (e.g., the Navy Marine Corps Intranet). </Definition>
		</Entry>
		<Entry>
			 <Term>DoD Information Assurance Certification and Accreditation Process (DIACAP).</Term>
			 <Definition>The DoD process for identifying, implementing, validating, certifying, and managing IA capabilities and services, expressed as IA controls, and authorizing the operation of DoD ISs, including testing in a live environment, in accordance with statutory, Federal, and DoD requirements. </Definition>
		</Entry>
		<Entry>
			 <Term>DoD Information Systems.</Term>
			 <Definition>Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. Includes AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections.
DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002</Definition>
		</Entry>
	</Section>
	<Section Letter="E">
		<Entry>
			 <Term>Enterprise Information Environment.</Term>
			 <Definition>The common, integrated information computing and communications environment of the GIG. The EIE is composed of GIG assets that operate as, provide transport for and/or assure local area networks, campus area networks, tactical operational and strategic networks, metropolitan area networks, and wide area networks. The EIE includes computing infrastructure for the automatic acquisition, storage, manipulation, management, control, and display of data or information, with a primary emphasis on DoD enterprise hardware, software operating systems, and hardware/software support that enable the GIG enterprise. The EIE also includes a common set of enterprise services, called Core Enterprise Services, which provide awareness of, access to, and delivery of information on the GIG.
DoD Directive 8115.01, “Information Technology Portfolio Management,”</Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="F">
		<Entry>
			 <Term>No terms for F</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="G">
		<Entry>
			 <Term>Global Information Grid (GIG).</Term>
			 <Definition>The globally interconnected, end-to-end set of information capabilities, associated processes, and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers, and support personnel. The GIG includes all owned and leased communications and computing systems and services, software (including applications), data, security services, and other associated services necessary to achieve Information Superiority. It also includes National Security Systems as defined in section 5142 of the Clinger-Cohen Act of 1996. The GIG supports all Department of Defense, National Security, and related Intelligence Community missions and functions (strategic, operational, tactical, and business), in war and in peace. The GIG provides capabilities from all operating locations (bases, posts, camps, stations, facilities, mobile platforms, and deployed sites). The GIG provides interfaces to coalition, allied, and non-DoD users and systems.
The GIG includes any system, equipment, software, or service that meets one or more of the following criteria:&#10;1. Transmits information to, receives information from, routes information among, or interchanges information among other equipment, software, and services.&#10;2. Provides retention, organization, visualization, information assurance, or disposition of data, information, and/or knowledge received from or transmitted to other equipment, software, and services.&#10;3. Processes data or information for use by other equipment, software, or services.
DoD Directive 8100.1, “Global Information Grid (GIG) Overarching Policy,”</Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="H">
		<Entry>
			 <Term>No terms for H</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="I">
		<Entry>
			 <Term>Impact Code.</Term>
			 <Definition>For the purpose of this Instruction, a code indicating the consequences of a non-compliant IA control. It is an indicator of the impact associated with exploitation of the IA control. In conjunction with the severity category, it also indicates the urgency with which corrective action should be taken. Impact codes are expressed as high, medium, and low, with high indicating the greatest impact. &#10;High Impact Code. The absence or incorrect implementation of the IA control may have a severe or catastrophic effect on system operations, management, or information sharing. Exploitation of the weakness may result in the destruction of information resources and/or the complete loss of mission capability. &#10;Medium Impact Code. The absence or incorrect implementation of the IA control may have a serious adverse effect on system operations, management, or information sharing. Exploitation of the weakness may result in loss of information resources and/or the significant degradation of mission capability.&#10;Low Impact Code. The absence or incorrect implementation of the IA control may have a limited adverse effect on system operations, management, or information sharing. Exploitation of the weakness may result in temporary loss of information resources and/or limit the effectiveness of mission capability.</Definition>
		</Entry>
		<Entry>
			 <Term>Implementation Procedures.</Term>
			 <Definition>Procedures describing the required steps and providing guidance for implementing DoD IA controls. Implementation procedures are found in the DIACAP KS. </Definition>
		</Entry>
		<Entry>
			 <Term>Information Assurance (IA).</Term>
			 <Definition>Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and nonrepudiation.  This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. Also called IA.
Joint Pub 1-02</Definition>
		</Entry>
		<Entry>
			 <Term>Information Assurance Control.</Term>
			 <Definition>An objective IA condition of integrity, availability or confidentiality achieved through the application of specific safeguards or through the regulation of specific activities that is expressed in a specified format, i.e., a control number, a control name, control text, and a control class. Specific management, personnel, operational, and technical controls are applied to each DoD information system to achieve an appropriate level of integrity, availability, and confidentiality in accordance with OMB Circular A-130, "Management of Federal Information Resources, Transmittal 4," November 30, 2000.
DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002</Definition>
		</Entry>
		<Entry>
			 <Term>Information Assurance Manager (IAM).</Term>
			 <Definition>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).
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Information Assurance Officer (IAO).</Term>
			 <Definition>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).
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Information Assurance Support Environment.</Term>
			 <Definition>A web-based resource providing access to current DoD and Federal IA and IA-related policy and guidance, including recent and pending legislation.
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Information Owner.</Term>
			 <Definition>Official with statutory or operational authority for specified information and responsibility for establishing the controls for its generation, collection, processing, dissemination, and disposal.
Committee on National Security Systems Instruction No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006</Definition>
		</Entry>
		<Entry>
			 <Term>Information Resources.</Term>
			 <Definition>Information and related resources, such as personnel, equipment, and information technology.
Joint Pub 1-02</Definition>
		</Entry>
		<Entry>
			 <Term>Information System (IS).</Term>
			 <Definition>Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. Includes AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections (National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 4009, "National Information Systems Security Glossary," September 2000 modified to include the four DoD categories).
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Information System Security Engineering.</Term>
			 <Definition>An engineering process that captures and refines information protection requirements and ensures their integration into IT acquisition processes through purposeful security design or configuration.
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Interim Authorization to Operate (IATO).</Term>
			 <Definition>A temporary authorization to operate a DoD IS under the conditions or constraints enumerated in the accreditation decision. </Definition>
		</Entry>
		<Entry>
			 <Term>Interim Authorization to Test (IATT).</Term>
			 <Definition>A temporary authorization to test a DoD IS in a specified operational information environment or with live data for a specified time period within the timeframe and under the conditions or constraints enumerated in the accreditation decision. </Definition>
		</Entry>
		<Entry>
			 <Term>IT Security Plan of Action and Milestones (POA&M).</Term>
			 <Definition>A permanent record that identifies tasks to be accomplished in order to resolve security weaknesses. Required for any accreditation decision that requires corrective actions, it specifies resources required to accomplish the tasks enumerated in the plan and milestones for completing the tasks. Also used to document DAA-accepted non-compliant IA controls and baseline IA controls that are not applicable. An IT Security POA&M may be active or inactive throughout a system’s life cycle as weaknesses are newly identified or closed. </Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="J">
		<Entry>
			 <Term>No terms for J</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	<Section Letter="K">
		<Entry>
			 <Term>No terms for K</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	<Section Letter="L">
		<Entry>
			 <Term>No terms for L</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="M">
		<Entry>
			 <Term>Mission Area (MA).</Term>
			 <Definition>A defined area of responsibility with functions and processes that contribute to mission accomplishment.
DoD Directive 8115.01, “Information Technology Portfolio Management,”</Definition>
		</Entry>
		<Entry>
			 <Term>Mission Assurance Category (MAC).</Term>
			 <Definition>Applicable to DoD information systems, the mission assurance category reflects the importance of information relative to the achievement of DoD goals and objectives, particularly the warfighters' combat mission. Mission assurance categories are primarily used to determine the requirements for availability and integrity. The Department of Defense has three defined mission assurance categories:&#10;Mission Assurance Category I (MAC I). Systems handling information that is determined to be vital to the operational readiness or mission effectiveness of deployed and contingency forces in terms of both content and timeliness. The consequences of loss of integrity or availability of a MAC I system are unacceptable and could include the immediate and sustained loss of mission effectiveness. MAC I systems require the most stringent protection measures.&#10;Mission Assurance Category II (MAC II). Systems handling information that is important to the support of deployed and contingency forces. The consequences of loss of integrity are unacceptable. Loss of availability is difficult to deal with and can only be tolerated for a short time. The consequences could include delay or degradation in providing important support services or commodities that may seriously impact mission effectiveness or operational readiness. MAC II systems require additional safeguards beyond best practices to ensure adequate assurance.&#10;Mission Assurance Category III (MAC III). Systems handling information that is necessary for the conduct of day-to-day business, but does not materially affect support to deployed or contingency forces in the short-term. The consequences of loss of integrity or availability can be tolerated or overcome without significant impacts on mission effectiveness or operational readiness. The consequences could include the delay or degradation of services or commodities enabling routine activities. MAC III systems require protective measures, techniques or procedures
generally commensurate with commercial best practices.
DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002</Definition>
		</Entry>
	</Section>
	<Section Letter="N">
		<Entry>
			 <Term>Net-centric.</Term>
			 <Definition>Relating to or representing the attributes of net-centricity. Netcentricity is a robust, globally interconnected network environment (including infrastructure, systems, processes, and people) in which data is shared timely and seamlessly among users, applications, and platforms. Net-centricity enables substantially improved military situational awareness and significantly shortened decision making cycles. Net-Centric capabilities enable network-centric operations and NCW.
DoDD 8320.2</Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="O">
		<Entry>
			 <Term>No terms for O</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="P">
		<Entry>
			 <Term>Platform IT Interconnection.</Term>
			 <Definition>For DoD IA purposes, platform IT interconnection refers to network access to platform IT. Platform IT interconnection has readily identifiable security considerations and needs that must be addressed in both acquisition, and operations. Platform IT refers to computer resources, both hardware and software, that are physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems such as weapons, training simulators, diagnostic test and maintenance equipment, calibration equipment, equipment used in the research and development of weapons systems, medical technologies, transport vehicles, buildings, and utility distribution systems such as water and electric. Examples of platform IT interconnections that impose security considerations include: communications interfaces for data exchanges with enclaves for mission planning or execution, remote administration, and remote upgrade or reconfiguration (DoD Directive 8500.1, "Information Assurance," October 24, 2002).
DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003</Definition>
		</Entry>
		<Entry>
			 <Term>Principal Accrediting Authority (PAA).</Term>
			 <Definition>The senior official representing the interests of a GIG MA regarding C&A. Also issues C&A guidance specific to a GIG MA as required. </Definition>
		</Entry>
		<Entry>
			 <Term>Program Manager or System Manager (PM or SM).</Term>
			 <Definition>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. </Definition>
		</Entry>
		<Entry>
			 <Term>Proxy.</Term>
			 <Definition>Software agent that performs a function or operation on behalf of another application or system while hiding the details involved. Typical proxies accept a connection from a user, make a decision as to whether or not the user or client network address is authorized to use the requested service, optionally perform additional authentication, and then complete a connection on behalf of the user to a remote destination.
DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002</Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="Q">
		<Entry>
			 <Term>No terms for Q</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="R">
		<Entry>
			 <Term>Residual Risk.</Term>
			 <Definition>Portion of risk remaining after security measures have been applied.
Committee on National Security Systems Instruction No. 4009, “National Information Assurance (IA) Glossary,” as revised June 2006</Definition>
		</Entry>
	</Section>
	<Section Letter="S">
		<Entry>
			 <Term>Security Relevant Event.</Term>
			 <Definition>For the purpose of this Instruction, an event that could cause a harmful change in an IS or its environment, or that an IAM would consider worthy of notation, investigation, or prevention (e.g., the discovery of malicious code in an IS, the discovery of an attempt to connect an unapproved device to the network). </Definition>
		</Entry>
		<Entry>
			 <Term>Senior Information Assurance Officer (SIAO).</Term>
			 <Definition>The official responsible for directing an organization’s IA program on behalf of the organization’s chief information officer. </Definition>
		</Entry>
		<Entry>
			 <Term>Service-Oriented Architecture.</Term>
			 <Definition>For the purpose of this Instruction, a paradigm for defining, organizing, and using distributed capabilities in the form of loosely coupled software services that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with, and use capabilities to produce desired effects that are consistent with measurable preconditions and expectations. </Definition>
		</Entry>
		<Entry>
			 <Term>Severity Category.</Term>
			 <Definition>The category a CA assigns to a system security weakness or shortcoming as part of a certification analysis to indicate the risk level associated with the security weakness and the urgency with which the corrective action must be completed. Severity categories are expressed as “Category (CAT) I, CAT II, or CAT III,” with CAT I indicating the greatest risk and urgency. Severity categories are assigned after consideration of all possible mitigation measures that have been taken within system design/architecture limitations for the DoD IS in question. &#10;CAT I Severity Category. Assigned to findings that allow primary security protections to be bypassed, allowing immediate access by unauthorized personnel or unauthorized assumption of super-user privileges. An ATO will not be granted while CAT I weaknesses are present. &#10;CAT II Severity Category. Assigned to findings that have a potential to lead to unauthorized system access or activity. CAT II findings that have been satisfactorily mitigated will not prevent an ATO from being granted.&#10;CAT III Severity Category. Assigned findings that may impact IA posture but are not required to be mitigated or corrected in order for an ATO to be granted.</Definition>
		</Entry>
		<Entry>
			 <Term>Stand-Alone Information System.</Term>
			 <Definition>An information system operating independently of and without interconnection to any other information system. </Definition>
		</Entry>
		<Entry>
			 <Term>System Identification Profile (SIP).</Term>
			 <Definition>A compiled list of system characteristics or qualities required to register an IS with the governing DoD Component IA program. </Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="T">
		<Entry>
			 <Term>No terms for T</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="U">
		<Entry>
			 <Term>User Representative (UR).</Term>
			 <Definition>An individual or organization that represents the user community for a particular system for DIACAP purposes. </Definition>
		</Entry>
	</Section>
	<Section Letter="V">
		<Entry>
			 <Term>Validation.</Term>
			 <Definition>Activity applied throughout the system’s life cycle to confirm or establish by testing, evaluation, examination, investigation, or competent evidence that a DoD IS’s assigned IA controls are implemented correctly and are effective in their application. </Definition>
		</Entry>
		<Entry>
			 <Term>Validation Procedure.</Term>
			 <Definition>Preparatory steps and conditions, actual validation steps, expected results, and criteria and protocols for recording actual results that are used for validating IA controls. May include associated supporting background material, sample results, or links to automated testing tools. </Definition>
		</Entry>
		<Entry>
			 <Term>Validator.</Term>
			 <Definition>Entity responsible for conducting a validation procedure. </Definition>
		</Entry>
	</Section>
	<Section Letter="W">
		<Entry>
			 <Term>Web Services.</Term>
			 <Definition>Self-describing, self-contained, modular units of software application logic that provide defined business functionality. Web services are consumable software services that typically include some combination of business logic and data. Web services can be aggregated to establish a larger workflow or business transaction. Inherently, the architectural components of Web services support messaging, service descriptions, registries, and loosely coupled interoperability. </Definition>
		</Entry>
	</Section>
	<!--
	<Section Letter="X">
		<Entry>
			 <Term>No terms for X</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	<Section Letter="Y">
		<Entry>
			 <Term>No terms for Y</Term>
			 <Definition></Definition>
		</Entry>
	</Section>
	-->
	<Section Letter="Z">
		<Entry>
			 <Term>Zimbabwe</Term>
			 <Definition>A country in Africa</Definition>
		</Entry>
	</Section>
</Glossary>
