https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN42903-PPM_CIO-059-000-WEB-1.pdf
DEPARTMENT OF THE ARMY
CHIEF INFORMATION OFFICER
107 ARMY PENTAGON
WASHINGTON DC 20310-0107
ADD-GOV-DS-059
SAIS-ADD (25-1rrrr) 28 January 2025
MEMORANDUM FOR SEE DISTRIBUTION
SUBJECT: Data Aggregation Framework
1. References. See Enclosure 1.
2. Purpose. Provide amplifying guidance to reference 1a on data management—
specifically, data aggregation.0F
1
a. This memorandum provides a framework for assessing and mitigating risks as
part of the data management and product development lifecycles.
b. The framework ensures the sensitivity of data (including data, metadata, and data
products1F
2) is established and any associated risks are identified and mitigated to ensure
proper data management and protection are implemented. This includes any time that
data is aggregated whether a data product is deployed, two or more data products are
joined, a new system is developed, or any other actions where the aggregation of data
may be a concern.
3. Background.
a. Reference 1b identifies “Data Protect” as a key strategic effort to the Army Data
Plan, to “develop Enterprise-wide policy and guidance for the Army to specify, when
data is aggregated and integrated into operations…The term ‘aggregation’ is used here
in the sense of associating data describing one set of information to data for a different
set of information.” Additionally, data protection directly supports VAULTIS (Visible,
Accessible, Understandable, Linked, Trustworthy, Interoperable, and Secure) goals,
specifically the “S – Secure” aspect.
b. Data protection is critical to achieve information advantage and deliver cutting-
edge and uncompromised capabilities. Data (including metadata) is an Army asset,
ownership and protection of that data is an Army mission and priority. To be effective,
the Army must improve its efforts to safeguard mission and business data (including any
1 As defined in reference 1f. This may implicate or involve “compilation” as defined in reference 1g, if
determined by an Original Classification Authority.
2 As defined in reference 1h.
SAIS-ADD (25-1rrrr)
SUBJECT: Data Aggregation Framework
metadata) through its entire lifecycle. Security and protection require the
implementation and enforcement of proper management and operational procedures by
the entire organization. This includes Commanders and senior leaders who provide the
strategic vision and goals for the organization, to strategic planners as well as program,
project, and program managers (PMs), down to everyone who helps the Army deploy,
fight, and win our nation’s wars. Furthermore, everyone, at all echelons and all levels,
is responsible for procedural compliance with the proper practices and procedures for
safeguarding data, information, and information technology.
4. Applicability.
a. This memorandum applies to the entire Army Data Enterprise as defined in
reference 1c. This includes, but not be limited to, Commanders and senior leaders of
agencies and activities at all levels and those they appoint, to include—
(1) Chief Information Officers (CIOs)
(2) Chief Innovation Officers
(3) Program Managers (PMs)
(4) System Owners
(5) Application Owners
(6) IT Service Owners
(7) Information Owners
(8) Portfolio Managers
(9) Resource Managers
(10) Security Managers
(11) Records Officers
(12) Operations Security Practitioners
(13) Acquisition Senior and Functional Services Managers
2
SAIS-ADD (25-1rrrr)
SUBJECT: Data Aggregation Framework
b. These roles are accountable for the implementation and enforcement of the Data
Aggregation Framework (Enclosure 2) and will ensure individual and organizational
accountability for activities under their purview.
5. Way Ahead. Implementation of the new Data Aggregation Framework will require a
phased approach. This memorandum is intended to be iterative over the first year
of implementation. The Chief Data and Analytics Officer (CDAO) will request feedback
from the data governance community and capture lessons learned to incorporate into
future iterations of the memorandum which will be rewritten on an annual basis. The
Department of Defense (DoD) will also publish future implementation guidance and
develop data protection policies through the DoD CDAO. The future update of
references 1c–e or a new regulation will incorporate this data protection policy.
6. Compliance. All organizations must comply with and are responsible for compliance
with all applicable laws, regulations, and policies to manage and protect data.
7. Points of contact.
a. CIO Policy Inbox at usarmy.pentagon.hqda-cio.mbx.policy-inbox@army.mil
b. OCIO, Data Integration Division, at usarmy.data.management@army.mil
c. Mr. Alfred Hull, Data Integration Division, alfred.d.hull2.civ@army.mil
Encls LEONEL T. GARCIGA
Chief Information Officer
DISTRIBUTION:
Principal Officials of Headquarters, Department of the Army
Commander
U.S. Army Forces Command
U.S. Army Training and Doctrine Command
U.S. Army Materiel Command
U.S. Army Futures Command
U.S. Army Pacific
U.S. Army Europe and Africa
U.S. Army Central
U.S. Army North
(CONT)
3
SAIS-ADD (25-1rrrr)
SUBJECT: Data Aggregation Framework
DISTRIBUTION: (CONT)
U.S. Army South
U.S. Army Special Operations Command
Military Surface Deployment and Distribution Command
U.S. Army Space and Missile Defense Command/Army Strategic Command
U.S. Army Cyber Command
U.S. Army Medical Command
U.S. Army Intelligence and Security Command
U.S. Army Corps of Engineers
U.S. Army Military District of Washington
U.S. Army Test and Evaluation Command
U.S. Army Human Resources Command
U.S. Army Corrections Command
Superintendent, U.S. Military Academy
Commandant, U.S. Army War College
Director, U.S. Army Civilian Human Resources Agency
Executive Director, Military Postal Service Agency
Director, U.S. Army Criminal Investigation Division
Director, Civilian Protection Center of Excellence
Superintendent, Arlington National Cemetery
Director, U.S. Army Acquisition Support Center
CF:
Principal Cyber Advisor
Director of Enterprise Management
Director, Office of Analytics Integration
Commander, Eighth Army
4
REFERENCES
a. AR 25-1 (Army Information Technology).
b. HQDA EXORD 009-20 (Army Data Plan Implementation in Support of Cloud
Migration), November 2019.
c. HQDA CIO memorandum (Army Data Stewardship Roles and Responsibilities
(Fiscal Year 2024)), 2 April 2024. Available at
https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN40630-PPM_CIO-021-000-WEB-1.pdf.
d. DoDI 8320.07 (Implementing the Sharing of Data, Information, and Information
Technology (IT) Services in the Department of Defense).
e. DoDI 8510.01 (Risk Management Framework for DoD Systems).
f. CNSSI 4009 (Committee on National Security Systems (CNSS) Glossary).
g. AR 380-5 (Army Information Security Program).
h. HQDA CIO memorandum (Army Enterprise Data Product Definition),
18 July 2024. Available at https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN41492-
PPM_CIO-036-000-WEB-1.pdf.
i. NIST slide presentation (NIST Risk Management Framework Quick Start Guide,
RMF Roles and Responsibilities Crosswalk), September 2024. Available at:
https://csrc.nist.gov/CSRC/media/Projects/risk-
management/documents/Additional%20Resources/NIST%20RMF%20Roles%20and%2
0Responsibilities%20Crosswalk.pdf.
j. DoD Architecture Framework (DoDAF) Version 2.02, August 2010. Available at
https://dodcio.defense.gov/Library/DoD-Architecture-Framework/
k. EO 13526 (Classified National Security Information), 29 December 2009.
l. National Security Presidential Memorandum 28 (The National Operations
Security Program), 13 January 2021. Available via ncsc_etd_partnership@odni.gov
m. DoDI 8320.02 (Sharing Data, Information, and Information Technology (IT)
Services in the Department of Defense).
n. DoDM 5200.01, Volume 1 (DoD Information Security Program: Overview,
Classification, and Declassification), 24 February 2012.
o. DoDM 5200.45 (Original Classification Authority and Writing a Security
Classification Guide).
ENCLOSURE 1
p. DoDM 5205.02 (DoD Operations Security (OPSEC) Program Manual).
q. AR 25-2 (Army Cybersecurity).
r. AR 25-22 (The Army Privacy and Civil Liberties Program).
s. AR 25-400-2 (Army Records Management Program).
t. AR 381-20 (The Army Counterintelligence Program).
u. AR 530-1 (Operations Security).
v. Army Techniques Publication 3-13.3 (Army OPSEC at Division and Below).
w. HQDA ASA (ALT) and CIO (Army Unified Data Reference Architecture, v.1.0), 22
March 2024. Available at
https://api.army.mil/e2/c/downloads/2024/03/25/c3d9b3aa/udra-version-1-0-final.pdf.
2
DATA AGGREGATION FRAMEWORK PROCESS
1. Data must be protected from unauthorized access, unauthorized use by authorized
personnel, and as otherwise required by law, regulation, or policy. The Data
Aggregation Framework outlines a process to identify, assess, and mitigate risks as part
of the data management and product development lifecycles in collaboration with
stakeholders to meet these requirements.
2. Information systems are already required to have controls (e.g., cybersecurity plans,
privacy plans, access control policies, etc.) in place to meet the requirements identified
in paragraph 1. System Owners may comply with the Data Aggregation Framework by
certifying annually from this point forward that:
a. The system has a current Authority to Operate (ATO).
b. The objectives for each Data Aggregation Framework step were evaluated as
part of the system’s risk management process to obtain an ATO.
c. Controls are in place to protect the data contained within the system.
d. The certification is stored in the Army Data Catalog.
3. Data Aggregation Framework Six-Step Process Overview. The Data Aggregation
Framework, illustrated in Figure 1, is a six-step process for data governance roles to
follow to ensure the protection of data products as they move across the enterprise and
are linked or aggregated with other data products.
Figure 1. Data Aggregation Framework
ENCLOSURE 2
4. The Data Aggregation Framework is risk-based and is composed of three
elements—
a. Identification of the security risk based on data exposure.
b. Specifying the data protection techniques to be used to protect the information
and limit the risk of exposure.
c. Performing a risk assessment and creating measurement/monitoring mechanisms
against exposure through vulnerabilities of data: data inference and data aggregation.
5. Escalation Process. For any conflicts during this process that cannot be resolved,
the matter should be escalated to the next higher level of data stewardship (see
Figure 2).
Figure 2. Escalation Structure
6. Data Aggregation Framework Six Steps.
a. Step 1: Risk Identification
(1) Objectives. To complete the essential activities to identify risks anytime data
assets are being aggregated.
2
(2) Stakeholders. The Office of Primary Responsible (OPR) designee0F
1 leads the
effort and engages with other stakeholders to leverage existing processes to identify
risks1F
2. These individuals or organizations may include—
(a) System Owners
(b) Other Data Stewardship Personnel (i.e., Functional Data Managers (FDM),
Data Stewards, and Mission Area Data Officers (MADO))
(c) Original Classification Authorities (OCA)
(d) Operations Security (OPSEC) Practitioners
(e) Cybersecurity Practitioners (i.e., Information System Security Managers
(ISSM), Information System Security Officers (ISSO), etc.)
(f) Army Records Management Office
(g) Army Privacy and Civil Liberties Office
(h) Any other required personnel or organizations that may be identified.
(3) Actions. The OPR designee must, at a minimum—
(a) Follow the OPSEC Planning Cycle to preserve friendly essential secrecy by
identifying, controlling, and protecting Critical Information Indicators (CII) and Critical
Program Information (CPI).
(b) Identify and follow other processes that may be required based upon the
nature of the data assets.
(c) Review the data models (i.e., conceptual2F
3 and logical3F
4 data models), business
processes, and workflows available through the planned data products.
(d) Notify the appropriate OCA that a new or updated Security Classification
Guide (SCG) may be needed.
1 The OPR is the office or organization that is aggregating the data.
2 For non-binding guidance, see Encl 1, reference i.
3 A Conceptual Data Model “is used to document the business information requirements and structural
business process rules of the architecture. It describes the information that is associated with the
information of the architecture. Included are information items, their attributes or characteristics, and their
inter-relationships.” See Encl 1, reference j, https://dodcio.defense.gov/Library/DoD-Architecture-
Framework/dodaf20_div1/
4 A Logical Data Model “allows analysis of an architecture's data definition aspect, without consideration
of implementation specific or product specific issues. Another purpose is to provide a common dictionary
of data definitions to consistently express models wherever logical-level data elements are included in the
descriptions.” See Encl 1, reference j, https://dodcio.defense.gov/Library/DoD-Architecture-
Framework/dodaf20_div2/
3
(e) Notify the appropriate office of any risks or gaps that may require the need to
develop a new or updated Commander’s Critical Information List (CIL).
(4) Outcomes. The outcomes from this step should include, at a minimum—
(a) A list of the data assets involved with the effort with classifications according
to sensitivity, regulatory requirements, and impact.
(b) An understanding of the intended data actions (e.g., collection, retention,
logging, generation, transformation, use, disclosure, sharing, transmission, disposal,
etc.).
(c) A documented list of identified risks and the associated categories (e.g.,
privacy, integrity, confidentiality, availability, security, compliance, operational risks,
etc.).
(d) A list of personnel and organizations with equities in the data that need to be
involved in the process.
(e) A list of other processes that may be required based upon the nature of the
data assets.
b. Step 2: Risk Assessment
(1) Objectives. To understand, quantify, prioritize the risks identified; evaluate
the potential impact of each risk; and review and document the protections that are or
will be implemented on the data assets (e.g., access control policies4F
5, etc.).
(2) Actions. The OPR designee must, at a minimum, continue the relevant
actions identified in Step 1, collaborate with Data Consumers to identify the
requirements driving data requests and any limitations on uses of the data, and any
analyses necessary to accomplish the outcomes in this step.
(3) Outcomes. The outcomes from this step should include, at a minimum, a
prioritized list of the identified risks, a list of protections that are or will be implemented,
and an evaluation as to whether the intended use of the data by the Data Consumers is
in line with the authorized use of the data.
c. Step 3: Sensitivity Determination
(1) Objectives. To determine the sensitivity of the aggregated data assets;
review and evaluate the protections; and determine whether additional protections need
to be implemented.
5 While Application Programming Interfaces (APIs) and other data sharing/transfer methods may handle a
larger amount of data, access should be restricted to only the parts of the business process and workflow
that a user is authorized to view.
4
(2) Actions. The OPR designee must, at a minimum, continue the relevant
actions identified in prior steps and complete the necessary analyses to achieve the
outcomes in this step. Cases may arise where there are conflicting sensitivity
determinations from different perspectives involved in the data aggregation framework.
In this case, conflicting views should be elevated to the Army Data Board (ADB) and/or
Army Wide Capabilities Protection (AWCP) for socialization and reconciliation.
(3) Outcomes. The outcomes from this step should include, at a minimum, the
sensitivity of the data asset and an established baseline of protections that comply with
the requirements laid out by the appropriate office identified above.
d. Step 4: Re-examine and Re-assess
(1) Objectives. To review the intended data actions to ensure compliance with
the established protections baseline; review the artifacts (i.e., data models, business
processes, and workflows) available through the planned data products to ensure
compliance with the established protections baseline; and establish a data protection
agreement.
(2) Actions. The OPR designee must, at a minimum, continue the relevant
actions identified in prior steps, complete the required analyses to achieve the outcomes
in this step, and ensure a data protection agreement is established. The agreement
should be coordinated between all relevant Functional Data Managers. The data
protection agreement should address aggregation concerns, impact level, and potential
releasability to external entities, at a minimum. The agreement should be in a central
location where Data Consumers can access the document.
(3) Outcomes. The outcomes from this step should include, at a minimum, data
actions that comply with the established protections baseline; artifacts that comply with
the established protections baseline; and a completed data protection agreement.
e. Step 5: Implementation
(1) Objectives. To apply and operationalize the identified data asset protections
throughout the data asset lifecycle.
(2) Actions. The OPR designee must engage with the identified stakeholders to
ensure that the baseline protections are implemented and consistent throughout the
entire data asset lifecycle as well as complete the required analyses to achieve the
outcomes in this step.
(3) Outcomes. Baseline data asset protections are implemented throughout the
data asset lifecycle and implementation of the data protection is documented.
5
f. Step 6: Monitoring/Annual Reassessment
(1) Objectives. To evaluate the ongoing effectiveness of the data asset
protections, support compliance efforts, and complete the annual attestation.
(2) Actions. The OPR designee must implement continuous monitoring and
engage with the identified stakeholders to ensure that protections are evaluated
throughout the entire data asset lifecycle as well as complete the required analyses to
achieve the outcomes in this step. If at any time the protections are determined not to
be effective, the OPR must start at Step 1 and reevaluate the circumstances to make
sure the proper protections are in place. Any deficiencies in the protections must be
documented. If there are no deficiencies, annual certification is required to confirm data
asset protections are in place and are effective.
(3) Outcomes. Assessment documentation is maintained, and annual
attestations are completed.
6