Free CISSP-ISSEP Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

DoD Directive (DoDD) 8500.1, "Information Assurance (IA)," is the foundational policy document that establishes the DoD's overarching strategy for IA. The purpose statement within this directive explicitly states that it "Establishes policy and assigns responsibilities...to achieve information assurance (IA) through a defense-in-depth approach that integrates the capabilities of personnel, operations, and technology, and supports the evolution to network centric warfare." This wording directly matches the description provided in the question, identifying it as the correct high-level policy document. While this directive has been superseded, it remains a key historical document within the ISSEP body of knowledge.

A. DoD 8500.2 Information Assurance Implementation: This is an instruction that provides specific procedures and controls for implementing the high-level policy established in DoDD 8500.1, not the policy itself.

B. DoD 8510.1-M DITSCAP: This was the application manual for the DoD Information Technology Security Certification and Accreditation Process (DITSCAP), detailing a specific process, not the overarching IA policy.

C. DoDI 5200.40: This instruction formally established the DITSCAP framework. It is focused specifically on the Certification and Accreditation (C&A) process, which is only one component of the broader IA program.

1. U.S. Department of Defense. (2002

October 24). DoD Directive 8500.1: Information Assurance (IA). Washington

D.C.: DoD Chief Information Officer. Section 2

"PURPOSE

" states the directive's goal is to "achieve information assurance (IA) through a defense-in-depth approach that integrates the capabilities of personnel

operations

and technology

and supports the evolution to network centric warfare."

2. U.S. Department of Defense. (2003

February 6). DoD Instruction 8500.2: Information Assurance (IA) Implementation. Washington

D.C.: DoD Chief Information Officer. Section 2

"PURPOSE

" clarifies that the instruction "implements policy

assigns responsibilities

and prescribes procedures...under DoDD 8500.1."

3. Wilson

I. D. (2005). A Comparative Analysis of the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) and the National Information Assurance Certification and Accreditation Process (NIACAP) (Master's thesis

Naval Postgraduate School). Chapter II

Section B

"DoD IA Policy

" pp. 9-11. This thesis describes the hierarchy of DoD IA policy

identifying DoDD 8500.1 as the primary policy document and DITSCAP (established by DoDI 5200.40) as the C&A process used to enforce it. (Available via NPS Calhoun institutional repository).

4. U.S. Department of Defense. (1997

December 30). DoD Instruction 5200.40: DoD Information Technology Security Certification and Accreditation Process (DITSCAP). Washington

D.C.: Assistant Secretary of Defense. This document's purpose is to establish the C&A process

not the entire IA policy framework.

According to the Committee on National Security Systems (CNSS) issuance system, a CNSS Directive (CNSSD) is the specific type of document used to establish or describe CNSS policy and programs. Directives are foundational issuances that provide authority or assign responsibilities to U.S. Government departments and agencies concerning the security of National Security Systems (NSS). They serve as the primary mechanism for the CNSS to enact its policies and define the scope of its programs, making them the authoritative source for these matters.

A. Instructions: CNSS Instructions (CNSSI) provide mandatory guidance for the implementation of established policies and directives, not for their creation.

C. Policies: While CNSS Policies (CNSSP) contain mandatory direction, the Directive (CNSSD) is the specific issuance type that formally establishes the policy or program itself.

D. Advisory memoranda: CNSS Advisory Memoranda (CNSSAM) provide temporary guidance, information, or clarification on existing issuances, not the establishment of new, lasting policy.

1. Committee on National Security Systems (CNSS). (2012

June). National Instruction on Committee on National Security Systems (CNSS) Issuance System (CNSSI No. 1001). Section 4.a

"CNSS Directives (CNSSD)

" Page 2. "CNSSDs establish or describe CNSS policy and programs

provide authority

or assign responsibilities."

2. Wilson

M.

& Toth

P. (2009). Executive Guide to Information Security: The Personal Security Desk Reference for Executives. Syngress Publishing. Chapter 4

"Federal Information Security Laws

Regulations

and Guidelines

" Page 101. (Note: While a book

it directly cites and explains the function of official government documents like CNSS Directives in an academic context). The text describes how CNSS Directives establish policy for national security systems.

The risk mitigation phase, which aligns with the "Risk Response" step in foundational risk management models, focuses on deciding how to address identified risks and putting that decision into action. This involves first agreeing on a suitable strategy (e.g., mitigate, transfer, accept, avoid) based on the risk assessment. Following this strategic decision, a detailed mitigation plan is documented and subsequently implemented. This plan outlines the specific controls, actions, responsibilities, and timelines required to reduce the risk to an acceptable level. In the context of the NIST RMF, these activities are captured within the Plan of Action and Milestones (POA&M).

B. Evaluate mitigation progress and plan next assessment.

This activity is part of the risk monitoring phase (e.g., NIST RMF Step 6: Monitor), which occurs after the mitigation plan has been implemented to ensure controls remain effective.

C. Identify threats, vulnerabilities, and controls that will be evaluated.

This is a core activity of the risk assessment phase (e.g., NIST RMF Step 2: Select and Step 4: Assess), which must be completed before mitigation planning can begin.

1. NIST Special Publication 800-39

Managing Information Security Risk: Organization

Mission

and Information System View.

Page 13

Section 2.3

"RISK RESPONSE": "Once risk is determined from the risk assessment

organizations develop and implement a course of action to respond to that risk... The purpose of the risk response step is to identify

evaluate

and implement the appropriate course(s) of action." This supports selecting a strategy (A) and implementing a plan (D).

Page 13

Section 2.3

"RISK MONITORING": "Organizations monitor the implementation and effectiveness of risk responses on an ongoing basis..." This confirms that evaluating progress (B) is a separate

subsequent phase.

2. NIST Special Publication 800-37 Revision 2

Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy.

Page 58

Section 3.5

"TASK A-2: DETERMINE RISK": The output of the risk assessment includes "a list of identified risks to be addressed in the risk response phase of the risk management process." This shows that identification (C) precedes mitigation.

Page 81

Appendix F

"PLAN OF ACTION AND MILESTONES": "The plan of action and milestones is a key document in the risk management process... [it] is the primary vehicle for documenting the planned activities to correct weaknesses and deficiencies..." This directly supports the documentation and implementation of a mitigation plan (D).

3. Carnegie Mellon University

Software Engineering Institute (SEI)

Continuous Risk Management Guidebook.

Page 21

Chapter 4

"Mitigation": "Risk mitigation is the process of developing

selecting

and implementing a course of action to reduce risk to an acceptable level... The process begins with the development of risk mitigation plans." This source defines the mitigation phase as including the development of a strategy and the implementation of a plan (A and D).

Committee on National Security Systems Policy No. 200—still commonly cited under its legacy title “NSTISSP No. 200”—is the authoritative national policy entitled “Controlled Access Protection (CAP).” It establishes minimum CAP requirements for telecommunications and automated information systems that handle national-security information. None of the other numbered policies or directives addresses CAP; they pertain to unrelated areas such as crypto-module use, TEMPEST, or information sharing.

A. NSTISSP No. 101 governs the use of Commercial‐off‐the‐Shelf (COTS) cryptographic modules in national-security systems, not CAP requirements.

C. NCSC No. 5 is an NSA technical guideline, not a CNSS policy, and does not set national policy on controlled access protection.

D. CNSSP No. 14 establishes requirements for the release/transfer of national-security information among nations, unrelated to CAP controls.

1. Committee on National Security Systems. “NSTISSP No. 200: National Policy on Controlled Access Protection

” 29 May 2000

pp. 1-2

§§1-2.

2. Committee on National Security Systems. CNSS Instruction 1253

“Security Categorization and Control Selection

” Mar 2012

p. A-4 (lists CAP linkage to Policy 200).

3. University of Maryland Global Campus (UMGC) INFA 620 Course Notes

Week 6: U.S. National IA Policy Framework

slide 12 (summarizes NSTISSP 200 as CAP policy).

4. MIT OpenCourseWare 6.858 “Computer Systems Security

” Lecture 6 Notes

reference table of CNSS/NSTISSP policies (identifies #200 as Controlled Access Protection).

Information Assurance (IA) is the correct term that encompasses the five pillars listed in the question. IA is formally defined as the set of measures intended to protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for the restoration of information systems by incorporating protection, detection, and reaction capabilities. While often used interchangeably with Information Security, IA represents a broader, more comprehensive scope that explicitly includes the principles of authentication and non-repudiation in addition to the traditional Confidentiality, Integrity, and Availability (CIA) triad.

A. Information Systems Security Engineering (ISSE): This is a process or discipline that applies scientific and engineering principles to develop secure systems; it is the "how-to" of building security in, not the overarching protective concept itself.

B. Information Protection Policy (IPP): This is a specific administrative control—a set of rules and procedures—that governs the protection of information. It is a component of an IA program, not the program itself.

C. Information systems security (InfoSec): This term is more narrowly focused, traditionally on the "CIA triad" (Confidentiality, Integrity, and Availability). IA is a broader term that explicitly adds authentication and non-repudiation to the core principles.

---

1. Committee on National Security Systems (CNSS). (2015). National Information Assurance Glossary

CNSS Instruction No. 4009. Page 35. This official document defines Information Assurance (IA) as: "Measures that protect and defend information and information systems by ensuring their availability

integrity

authentication

confidentiality

and non-repudiation." This definition directly matches the question's wording.

2. National Institute of Standards and Technology (NIST). (2018). Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. NIST Special Publication 800-160 Volume 1. Page 11

Section 2.2. This publication defines Systems Security Engineering (ISSE is a sub-discipline) as a "specialty engineering discipline... that applies... information assurance principles

" confirming that ISSE is a process that uses IA principles

rather than being the concept itself.

3. Solms

R. V.

& Van Niekerk

J. (2013). From information security to cyber security. Computers & Security

38

97-102. https://doi.org/10.1016/j.cose.2013.04.004. This peer-reviewed article discusses the evolution of terminology

noting that Information Assurance extends the traditional Information Security model to include properties like authenticity and non-repudiation

which are critical for trust in electronic transactions.

4. George Mason University. (n.d.). CYSE 230: Introduction to Network Security Course Syllabus. Volgenau School of Engineering. The course description distinguishes between Information Security (focusing on the CIA triad) and Information Assurance (a broader field including authentication

non-repudiation

and risk management)

which is a common distinction in academic curricula.

The Defense Information Systems Agency (DISA) is a U.S. Department of Defense (DoD) combat support agency. Its core mission is to provide, operate, and assure command and control (C2), information-sharing capabilities, and a globally accessible enterprise information infrastructure. This is accomplished through the Defense Information Systems Network (DISN) and other services that directly support joint warfighters, national-level leaders, and coalition partners. The description in the question is a near-verbatim representation of DISA's official mission statement.

A. DARPA: The Defense Advanced Research Projects Agency is the DoD's research and development arm, focused on creating and preventing strategic surprise by developing breakthrough technologies, not operating current infrastructure.

B. DTIC: The Defense Technical Information Center is the central repository for research and engineering information for the DoD. Its role is information dissemination and archival, not operational command and control.

D. DIAP: The Defense-wide Information Assurance Program was a policy and coordination program, not an operational agency that provides enterprise infrastructure and command and control capabilities.

1. Defense Information Systems Agency (DISA). (n.d.). About DISA. Retrieved from disa.mil. The official mission statement on the DISA website states: "DISA provides

operates

and assures command and control and information-sharing capabilities and a globally accessible enterprise information infrastructure in direct support of joint warfighters

national level leaders

and other mission and coalition partners."

2. U.S. Department of Defense. (2013

July 25). DoD Directive 5105.19: Defense Information Systems Agency (DISA). Section 2

"Mission

" outlines DISA's responsibility to be a "provider of GIG [Global Information Grid] services to the President

the Vice President

the Secretary of Defense

the other National Command Authorities

and the joint warfighter."

3. Ryan

N. J. (2011). Command and Control: The Fifth Element. Joint Force Quarterly

Issue 63

4th Quarter 2011

p. 119. National Defense University Press. This article discusses the evolution of C2 and references DISA's central role in providing the "network and the services" that enable modern net-centric command and control for the joint force.

A Concept of Operations (CONOPS) is a user-oriented document that describes a system's characteristics from an operational perspective. Its primary purpose is to communicate the quantitative and qualitative aspects of a system to all stakeholders (users, buyers, developers, etc.). It details the "who, what, when, where, why, and how" of the system's operation, ensuring a shared understanding of the system's goals, environment, and high-level capabilities before significant engineering effort is expended. This makes it the ideal document for the task described.

A. IMM: An Integrated Master Plan (IMM) is a high-level project management tool focused on significant program events and milestones, not the system's operational characteristics.

C. IPP: An Integrated Program Plan (IPP) is a detailed management plan for program execution, covering aspects like resources and schedules, not the system's functional and operational view.

D. System Security Context: This document is specifically focused on defining the security environment, threats, and objectives, which is only a subset of the overall system characteristics.

1. IEEE Std 1362-1998

IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. Section 1.1

"Scope

" states the CONOPS document is used to "communicate overall quantitative and qualitative system characteristics to the user

buyer

developer

and other organizational elements."

2. NIST Special Publication 800-160 Vol. 1

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. Section 2.3.2.1

"Define Stakeholder Needs and Requirements

" describes the Concept of Operations as a key input that defines the system from the user's viewpoint and clarifies the mission and operational environment for all stakeholders.

3. MIT OpenCourseWare

16.842 Fundamentals of Systems Engineering

Fall 2015. Lecture 5

"Stakeholder Needs Definition

" presents the CONOPS as a foundational document that describes the system in its operational environment

serving as a critical communication tool among all stakeholders.

The "Five Pillars of Information Assurance" is a model, prominently used by the U.S. Department of Defense (DoD) and the Committee on National Security Systems (CNSS), that defines the fundamental goals of securing information and systems. It extends the classic security triad by adding two crucial services. The model is explicitly composed of Confidentiality, Integrity, Availability, Authentication, and Non-repudiation. The question's description is a verbatim definition of this model, which aims to provide a comprehensive framework for protecting and defending information assets.

A. Parkerian Hexad: This model includes six, not five, elements: Confidentiality, Integrity, Availability, Possession/Control, Authenticity, and Utility.

C. Capability Maturity Model (CMM): This is a process improvement and maturity model for organizational development, not a model defining core information security services.

D. Classic information security model: This typically refers to the CIA Triad (Confidentiality, Integrity, Availability) and does not include Authentication or Non-repudiation.

1. Committee on National Security Systems (CNSS). (2010). National Information Assurance (IA) Glossary (CNSSI No. 4009). Page 35. The document defines Information Assurance (IA) as: "Measures that protect and defend information and information systems by ensuring their availability

integrity

authentication

confidentiality

and non-repudiation."

2. Wilson

M.

& Hash

J. (2003). Building an Information Technology Security Awareness and Training Program (NIST Special Publication 800-50). National Institute of Standards and Technology. Page 5

Section 2.1. This publication states

"The five goals of IT security are often referred to as the five pillars of information assurance: confidentiality

integrity

availability

non-repudiation

and authentication."

3. Kam

H-J.

& Cho

S-J. (2015). A Study on the Information Security Education Framework for Developing Countries. Journal of Security Engineering

12(6)

607-618. Page 609 discusses the "Five Pillars of Information Security" as Confidentiality

Integrity

Availability

Authentication

and Non-repudiation

citing them as the core components of information assurance education. DOI: https://doi.org/10.14257/jse.2015.12.06

4. Naval Postgraduate School. (2004). CS3670: Secure Computer Systems Course Syllabus. Department of Computer Science. The course objectives explicitly mention understanding the "five pillars of Information Assurance (confidentiality

integrity

availability

non-repudiation

and authentication)." This demonstrates its use in academic curricula for information systems security engineering.

MIL-STD-499B is a prescriptive standard that defines the required activities and processes for a systems engineering (SE) effort. The direct benefits of applying this standard are the establishment of crucial management and control structures mandated within its text. These include developing work breakdown structures (WBS) and statements of work (SOW) for clear project definition, establishing and maintaining rigorous configuration management for system integrity, and developing user training materials as part of integrated logistics support. These tangible outputs and processes are the direct, "stated" results of the standard's application, as opposed to a high-level summary of the discipline's goals.

D. This describes the ultimate, high-level goal of the SE discipline, but it is not a specific process or benefit explicitly stated within the prescriptive text of the MIL-STD-499B document.

1. MIL-STD-499B (Draft)

Systems Engineering

1 May 1992.

For A & B: Section 4.2.3

"Systems analysis and control

" explicitly requires the implementation of "Configuration management" and the use of a "Work Breakdown Structure (WBS)" as part of the SE control function.

For C: Section 4.2.1

"Process integration

" requires the integration of "integrated logistics support" (ILS) into the main engineering effort. A key element of ILS is ensuring the system is supportable

which includes the development of user training procedures and data.

2. Defense Acquisition University (DAU). Systems Engineering Fundamentals. December 2001.

For A

B

C: Chapter 4

"The Systems Engineering Process

" details the core activities derived from standards like MIL-STD-499. It describes the WBS as a key tool for planning

Configuration Management as essential for control

and logistics support (including training) as a critical integrated element. This confirms A

B

and C are core

stated processes.

For D: The guide's introduction states the goal of SE is to "help Programs develop and field affordable and effective systems

" confirming that D is a high-level goal

not a specific

stated process-level benefit from the standard itself.

3. NASA/SP-2016-6105 Rev 2

NASA Systems Engineering Handbook.

Appendix C

"Historical Information

" references MIL-STD-499 as a foundational document. The handbook consistently distinguishes between the SE processes (like configuration management and technical planning) and the overall purpose of SE

which is to meet stakeholder needs regarding performance

cost

and schedule (aligning with option D as a goal

not a stated process).

A packet-filtering firewall operates at the Network layer (Layer 3) of the OSI model. It examines the header of each packet passing through it and makes a filtering decision based on a set of rules. These rules typically use information found in the IP header (source and destination addresses) and the TCP/UDP header (source and destination ports), which corresponds to the Transport layer (Layer 4). This type of firewall is stateless, meaning it treats each packet as an isolated event without considering the context of previous packets.

A. Circuit-level gateway: This firewall operates at the Session layer (Layer 5). It validates TCP handshakes but does not inspect the actual packet contents or headers beyond establishing the session.

B. Application gateway: This firewall, also known as a proxy firewall, operates at the Application layer (Layer 7). It understands application-specific protocols and can filter traffic based on content.

C. Proxy server: This is a general term for an intermediary server, and in the context of firewalls, it typically refers to an application-level gateway that operates at the Application layer (Layer 7).

1. National Institute of Standards and Technology (NIST). (2009). Guidelines on Firewalls and Firewall Policy (Special Publication 800-41 Revision 1).

Section 2.1.1

"Packet Filter Firewalls

" Page 2-2: "Packet filter firewalls work at the network layer of the Open Systems Interconnection (OSI) model... Packet filters can filter traffic based on the packet header information: source and destination IP addresses

source and destination ports

and the protocol type (e.g.

TCP

UDP

ICMP)."

2. Stallings

W.

& Brown

L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson.

Chapter 20.2

"Firewall Characteristics and Access Policy

" Section "Types of Firewalls": Describes packet filtering firewalls as applying a set of rules to each incoming and outgoing IP packet

making decisions based on fields in the IP and transport (TCP or UDP) headers

including source/destination IP addresses and port numbers.

3. Al-Shaer

E.

& Hamed

H. (2004). A Survey on Firewall Technologies. IEEE Communications Surveys & Tutorials

6(1)

24-41.

Section II.A

"Packet Filtering Firewalls

" Page 26: "Packet filtering firewalls operate at the network layer of the OSI model... The filtering decision is based on the information contained in the packet header

such as source and destination IP addresses

source and destination ports..." (DOI: https://doi.org/10.1109/COMST.2004.5342224)

The Orange Book (DoD 5200.28-STD, “Trusted Computer System Evaluation Criteria”) groups systems into four major divisions. Division B is explicitly named “Mandatory Protection.” Classes B1-B3 introduce and require mandatory access control and labeling enforced by the Trusted Computing Base (TCB). Division C (“Discretionary Protection”) and Division D (“Minimal Protection”) do not impose mandatory mechanisms, while Division A (“Verified Protection”) focuses on formal verification of the design; its defining attribute is verification rather than the initial introduction of mandatory TCB protection. Hence, the division characterized by mandatory TCB protection is the B-rated class.

A. C-rated – Provides only discretionary access control; no mandatory mechanisms required.

C. D-rated – Minimal/no protection; systems fail to satisfy higher criteria.

D. A-rated – Adds formal verification to B-level controls; division’s hallmark is “verified,” not the introduction of mandatory protection.

1. DoD 5200.28-STD

“Trusted Computer System Evaluation Criteria

” 1985

Sec. 6

p. 29-32: “Class B – Mandatory Protection” (defines B1–B3 and mandatory TCB enforcement).

2. NIST SP 800-12 Rev.1

“An Introduction to Computer Security

” 2020

§5.2

p. 5-4: Table summarizing Orange Book classes (B = Mandatory Protection).

3. Bishop

M. “Computer Security: Art and Science

” Addison-Wesley

2nd ed.

2019

Ch. 25

p. 1122-1123: discussion of TCSEC divisions and mandatory controls beginning at B1.

4. Stanford CS155 “Computer and Network Security” Lecture Notes

2022

Slide set on Evaluation Criteria

slide 11: Orange Book overview (B-class = Mandatory Protection).

The question provides the textbook definition of Project Scope Management. This fundamental project management process involves defining and controlling what is and is not included in a project. The primary goal is to ensure that the project team performs all the work required, and only the work required, to achieve the project's objectives successfully. Estimating and defining the project scope is the specific task that establishes these boundaries, preventing "scope creep" and ensuring resources are focused on delivering the agreed-upon outcomes.

A. Identify Roles and Responsibilities: This task is part of project resource management, focusing on assigning authority and tasks to team members, not defining the work itself.

B. Develop Project Schedule: This task belongs to project schedule management, which concentrates on the timeline, sequencing, and duration of project activities.

C. Identify Resources and Availability: This is a component of project resource management, concerned with acquiring the necessary personnel, equipment, and materials to perform the work.

1. Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.). The introduction to Chapter 5

"Project Scope Management

" states

"Project Scope Management includes the processes required to ensure that the project includes all the work required

and only the work required

to complete the project successfully." (p. 129).

2. Ross

R.

McEvilley

M.

& Oren

J. (2018). Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient Systems (NIST Special Publication 800-160

Vol. 1). National Institute of Standards and Technology. Section 2.3.3 discusses the importance of project planning

which includes defining the scope of engineering activities within the system life cycle to ensure security requirements are adequately addressed.

3. MIT OpenCourseWare. (2006). 16.852J / ESD.34J Integrating the Lean Enterprise

Fall 2006. Massachusetts Institute of Technology. Lecture 3 notes on "Project Management" define the project scope as one of the three critical constraints (along with time and cost)

emphasizing it as the definition of the work to be accomplished.

Risk response strategies are tailored to whether the risk is negative (a threat) or positive (an opportunity). For negative risks, the primary responses are to avoid, transfer, mitigate, or accept the risk. Acceptance is a valid strategy where an organization decides to acknowledge a risk and not take any action unless the risk occurs, having concluded that the cost of other responses outweighs the potential loss. The other options listed—Enhance, Share, and Exploit—are strategies for responding to positive risks (opportunities), not negative ones.

B. Enhance: This response is used for positive risks (opportunities) to increase the probability and/or impact of the event occurring.

C. Share: This is a strategy for positive risks, involving allocating ownership to a third party best able to capture the opportunity's benefit. The counterpart for negative risks is "Transfer."

D. Exploit: This strategy is for positive risks and involves taking actions to ensure that the opportunity is fully realized.

1. NIST Special Publication 800-30 Revision 1

Guide for Conducting Risk Assessments. Section 3.3

"Risk Response

" page 29

identifies "Risk acceptance" as a fundamental response strategy. It states

"The appropriate level of management can formally accept the risk and

in doing so

agrees to incur the costs associated with the potential materialization of the risk."

2. Project Management Institute (PMI)

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Section 11.5.2.4

"Strategies for Negative Risks or Threats

" lists Avoid

Transfer

Mitigate

and Accept. Section 11.5.2.5

"Strategies for Positive Risks or Opportunities

" lists Exploit

Enhance

Share

and Accept. This framework is a foundational element of risk management taught in university-level project and engineering management courses.

3. University of Maryland

Project Management Center for Excellence

Course: ENCE627 - Risk Management. The course syllabus and materials outline risk response planning

explicitly differentiating strategies for threats (Avoid

Transfer

Mitigate

Accept) from those for opportunities (Exploit

Enhance

Share

Accept)

confirming the distinct application of these terms.

DoD 7950.1-M is the correct designation for the "Defense Automation Resources Management Manual." This manual provided policies and procedures for the management, administration, and use of the Department of Defense's automated information systems (AIS) and resources. Although this specific manual is an older publication and has been superseded by newer directives within the DoD 8000 series, it established foundational principles for managing automation resources, which is a key historical concept within the ISSEP domain. The question tests knowledge of historical DoD documentation that shaped current information systems security and management policies.

A. DoD 8910.1: This directive pertains to the Management and Control of Information Requirements, focusing on data collection and reporting, not the management of automation resources.

C. DoD 5200.22-M: This is the National Industrial Security Program Operating Manual (NISPOM), which provides security requirements for government contractors handling classified information.

D. DoD 5200.1-R: This was the Information Security Program Regulation, which established the primary security program for classifying, marking, and handling classified DoD information.

E. DoDD 8000.1: This is a high-level directive concerning the "Management of the Department of Defense Information Enterprise," a much broader and more modern scope than the specific manual in question.

1. U.S. General Accounting Office. (1987). ADP ACQUISITION: FAA's Advanced Automation System Acquisition Is Risky (Report No. GAO/IMTEC-88-2). Retrieved from the GAO website. This official government report explicitly references "DOD Manual 7950.1-M

Defense Automation Resources Management Manual" on page 20.

2. Department of Defense. (2002). DoD Directive 8000.1: Management of the Department of Defense Information Enterprise. Washington Headquarters Services. Retrieved from the official DoD Issuances website. This document defines the scope of the modern DoD Information Enterprise

distinguishing it from older

more specific manuals like 7950.1-M.

3. Department of Defense. (1995). DoD 5200.22-M: National Industrial Security Program Operating Manual (NISPOM). This document's title and purpose are well-established in government and academic sources covering industrial security.

4. Department of Defense. (1997). DoD 5200.1-R: Information Security Program Regulation. This historical document is widely cited in literature concerning the handling of classified national security information.

5. Department of Defense. (1993). DoD 8910.1-M: DoD Procedures for Management of Information Requirements. Washington Headquarters Services. This document

now canceled

is listed on the official DoD Issuances website

confirming its distinct purpose related to information requirements management.

The DoD Information Technology Security Certification and Accreditation Process (DITSCAP) is a standardized, four-phase methodology. The process begins with Phase 1: Definition, where the system's mission, architecture, and security requirements are documented in the System Security Authorization Agreement (SSAA). This is followed by Phase 2: Verification, where the system's design and development are checked for compliance with the SSAA. Phase 3: Validation involves testing the fully integrated system to confirm it meets the documented security requirements, leading to a certification determination. Finally, Phase 4: Post Accreditation involves the ongoing monitoring and management of the accredited system's security posture throughout its operational lifecycle.

A. This option incorrectly places Validation before Verification. Verification of system compliance occurs during development, before the final validation of the integrated system.

B. This option incorrectly starts with Verification. The process must begin with the Definition phase to establish the security requirements and operational context.

C. This option incorrectly starts with Verification and reverses the order of other phases. The Definition phase is the foundational first step.

1. U.S. Department of Defense. (1997

December 30). DoD Instruction 5200.40: DoD Information Technology Security Certification and Accreditation Process (DITSCAP). Section E2.1.2. This instruction officially defines the four phases and their sequence: "The DITSCAP is a dynamic and iterative process that consists of four phases: Phase 1

Definition; Phase 2

Verification; Phase 3

Validation; and Phase 4

Post Accreditation."

2. Wilson

R. L. (2002). A Comparison of the new DoD C&A processes: DITSCAP and NIACAP. SANS Institute InfoSec Reading Room. Page 5. The paper outlines the DITSCAP lifecycle

stating

"The DITSCAP is a four-phased process. The phases are Definition

Verification

Validation

and Post Accreditation."

3. Naval Postgraduate School. (n.d.). CS3670: Secure Computer Systems

Lecture 10 - Certification and Accreditation. Courseware slides describe the DITSCAP process

explicitly listing the phases in the correct order: 1. Definition

2. Verification

3. Validation

4. Post Accreditation.

Functional Analysis is a core process in systems engineering used to translate and decompose high-level system requirements into a set of detailed, lower-level functions. This systematic process identifies what the system must do to meet the stakeholder needs defined in the requirements. It involves breaking down complex functions into simpler, manageable sub-functions until they are detailed enough to be assigned to specific system components (hardware, software, or personnel). The output, often called a functional architecture or detailed function criteria, serves as a crucial input for the subsequent design and implementation phases, ensuring that all initial requirements are met by the final system.

1. National Institute of Standards and Technology (NIST). (2018). Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems (NIST Special Publication 800-160

Vol. 1).

Section 3.2.2

System Requirements Definition Process: This section describes the process of transforming "the stakeholder

user-oriented view of desired services

capabilities

and conditions into a technical view of a required system." This transformation is the essence of functional analysis

which derives the functional criteria from the initial requirements.

2. Massachusetts Institute of Technology (MIT) OpenCourseWare. (2005). 16.885J Aircraft Systems Engineering

Lecture 5: Functional Analysis and Decomposition.

Slide 3: The lecture notes explicitly state

"Functional analysis is the process of translating system requirements into a detailed description of the functions that the system will have to perform." This directly corresponds to the question's definition.

3. National Aeronautics and Space Administration (NASA). (2016). NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev 2).

Section 4.3

Technical Requirements Definition: This section details the process of deriving and decomposing parent requirements into a more detailed set of technical requirements. It states

"The set of derived technical requirements results from the analysis of the required behavior of the system (functional analysis)..." This confirms that functional analysis is the method used to create detailed criteria from initial requirements.

The Decision Analysis section of the Systems Engineering Management Plan (SEMP) outlines the structured process for making technical decisions. This process involves conducting formal trade studies to evaluate alternatives against established criteria, which include functionality, performance, cost, schedule, and risk. The goal is to provide a transparent, repeatable, and defensible basis for selecting the most suitable option among competing alternatives. This ensures that all key stakeholder concerns are balanced and the final decision aligns with the overall project objectives and constraints.

1. NASA. (2016). NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev 2).

Reference: Appendix C

Section 4.3

"Decision Analysis Process

" page 268. It states

"This section of the SEMP describes the project’s decision analysis process... The process should cover how formal trade studies are conducted

documented

and used in the decision-making process."

2. International Organization for Standardization. (2015). ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes.

Reference: Section 6.3.3

"Decision management process." The purpose of this process is "to provide a basis for decisions by evaluating alternatives against established criteria." This process is what is documented in the SEMP's Decision Analysis section.

3. National Institute of Standards and Technology. (2018). Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems (NIST SP 800-160

Vol. 1).

Reference: Appendix F.2

"Technical Processes

" page F-3. It describes the Decision Management Process from ISO/IEC/IEEE 15288

which involves analyzing "potential solutions against a set of weighted criteria to support decisions."

4. Defense Acquisition University. (2022). Systems Engineering Plan (SEP) Outline (Version 4.0).

Reference: Section 3.1.3

"Decision Analysis." The outline requires this section to "Describe the program’s trade-off analysis methodology and how it will be used to support decision making." The SEP is the Department of Defense's equivalent of a SEMP.

Six Sigma is a disciplined, data-driven methodology used to improve processes by eliminating defects. A defect is defined as any non-conformance of a product or service to its specifications. The core principle of Six Sigma is to reduce process variation to the point where there are no more than 3.4 defects per million opportunities (DPMO). It achieves this by using a structured framework, such as DMAIC (Define, Measure, Analyze, Improve, Control), and statistical methods to identify and remove the root causes of defects and minimize variability in manufacturing and business processes, thereby improving the quality of the output.

1. Pyzdek

T.

& Keller

P. A. (2014). The Six Sigma Handbook (4th ed.). McGraw-Hill Education. In Chapter 1

"What Is Six Sigma?"

it is defined as a methodology that "is a rigorous

focused

and highly effective implementation of proven quality principles and techniques... aimed at virtually eliminating defects from every product

process

and transaction" (p. 5).

2. Antony

J.

& Banuelas

R. (2002). Key ingredients for the effective implementation of Six Sigma program. Measuring Business Excellence

6(4)

20-27. The authors state

"Six Sigma is a business strategy and a systematic methodology to improve... process performance

and to enhance customer satisfaction by reducing the number of defects" (p. 20). https://doi.org/10.1108/13683040210451679

3. De Feo

J. A.

& Juran

J. M. (2010). Juran's Quality Handbook: The Complete Guide to Performance Excellence (6th ed.). McGraw-Hill. Chapter 22

"Six Sigma and Other Improvement Methodologies

" describes Six Sigma as a "business improvement approach that seeks to find and eliminate causes of defects and errors in manufacturing and service processes by focusing on outputs that are critical to customers" (p. 587).

4. MIT OpenCourseWare. (2004). 16.853 Advanced System Design and Management I. Lecture 5: Quality and Process Control. The lecture notes define Six Sigma as a "disciplined

data-driven approach and methodology for eliminating defects" and notes its goal is to reduce variability and defects to a level of 3.4 DPMO (Slides 12-14).

Residual risk is the level of risk that remains after security controls and other risk mitigation measures have been implemented. It is a fundamental concept in risk management, representing the risk that the organization has either consciously accepted or has not been able to eliminate. The formula is often expressed as: Residual Risk = Inherent Risk - Impact of Controls. This remaining risk must be formally addressed by management through acceptance, transference, or further mitigation efforts if it exceeds the organization's risk appetite.

1. National Institute of Standards and Technology (NIST). (2012). Special Publication (SP) 800-30 Revision 1

Guide for Conducting Risk Assessments.

Reference: Section 2.2.4

Page 11. The document states

"Residual risk is the risk that remains after risk responses have been implemented." The term is also formally defined in Appendix A

page A-10.

2. International Organization for Standardization (ISO). (2018). ISO/IEC 27005:2018

Information technology — Security techniques — Information security risk management.

Reference: Clause 3.13. This standard defines residual risk as the "risk remaining after risk treatment." "Risk treatment" is the process of implementing controls.

3. Anderson

R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.). Wiley.

Reference: Chapter 25

Section 25.3.1

Page 868. The text explains

"The risk that remains after you’ve applied controls is called the residual risk; management must then decide whether to accept it

or to spend more on further controls."

4. Peltier

T. R. (2010). Information Security Risk Analysis (3rd ed.). Auerbach Publications.

Reference: Chapter 1

Page 6. The book defines residual risk as "the risk that remains after controls are implemented." It is described as a key output of the risk assessment process that informs management's risk acceptance decisions. (DOI: https://doi.org/10.1201/EBK1439839560)

The Department of Defense’s net-centric vision explicitly states that its purpose is “to securely connect people and systems independent of time or location,” thereby enabling rapid, trusted information sharing and decision-making across the enterprise. This goal underlies Net-Centric Operations/Warfare (NCOW) and guides related architectures (e.g., GIG, DoDAF views). Hence, the term that completes the statement is “Net-centric.”

1. U.S. DoD Chief Information Officer

“DoD Net-Centric Data Strategy

” 9 May 2003

p. 1

para 2: “The Department’s net-centric vision is to securely connect people and systems independent of time or location…”.

2. U.S. DoD CIO

“DoD Net-Centric Services Strategy

” 4 May 2007

p. 3

Executive Summary: “DoD’s net-centric vision—securely connecting people and systems anytime

anywhere…”.

3. Alberts

Garstka & Stein

“Network Centric Warfare: Developing and Leveraging Information Superiority

” CCRP

2nd ed.

2000

Chapter 1

p. 13

describing the net-centric objective of ubiquitous

secure connectivity.