Study guide
3.4 Data Handling and Marking Requirements
ISC2 Certified in Governance, Risk and Compliance CGRC
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 ISC2 CGRC Exam Structure, Logistics & Passing Strategy 0.2 NIST RMF 7-Step Lifecycle & GRC Architecture
2 Chapter 1: Security and Privacy Governance, Risk Management, and Compliance Program
1.1 Enterprise Governance & GRC Frameworks 1.2 Security and Privacy Objectives: CIA, Non-Repudiation and Privacy Concepts 1.3 Multi-Tier Risk Management & Assessment Methodologies 1.4 System Development Life Cycle and Information Life Cycle Management 1.5 Establishing and Operating the Compliance Program 1.6 Legal, Regulatory & Federal Compliance Drivers 1.7 Privacy Governance, Organizational Roles & ISC2 Code of Ethics
3 Chapter 2: Scope of the System
2.1 System Boundary Definition, Architectural Context & Types 2.2 Identifying Information Types with NIST SP 800-60 2.3 System Categorization Process & Impact Analysis (FIPS 199 / SP 800-60) 2.4 Impact and Risk Determination Under Non-Federal Frameworks 2.5 System Registration, Environment & Interconnection Agreements
4 Chapter 3: Selection and Approval of Framework, Security, and Privacy Controls
3.1 Control Catalogs & NIST SP 800-53 Rev. 5 Structure 3.2 Control Allocation & Inheritance Models 3.3 Control Tailoring, Scoping & Overlay Guidance 3.4 Data Handling and Marking Requirements 3.5 Documenting Control Selection and Securing Stakeholder Agreement 3.6 Continuous Monitoring Strategy & Control Selection Approval
5 Chapter 4: Implementation of Security and Privacy Controls
4.1 Developing the Implementation Strategy: Resourcing, Funding and Timeline 4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes 4.3 System Security and Privacy Plan (SSP/SSPP) Development 4.4 Security Engineering Principles & Technical Control Implementation 4.5 Secure Baseline Configuration & System Hardening 4.6 Implementing Compensating and Alternate Controls 4.7 DevSecOps, SDLC Integration & Supply Chain Risk Management 4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
6 Chapter 5: Assessment/Audit of Security and Privacy Controls
5.1 Security Assessment Plan (SAP) & Assessor Independence 5.2 Assessment Methods, Objects & Depth/Coverage 5.3 Assessment Execution, Vulnerability Scanning & Testing 5.4 Preparing the Initial Assessment/Audit Report 5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer 5.6 Stakeholder Collaboration, Corrective Action and Reassessment 5.7 Security Assessment Report (SAR) & Risk Findings Analysis 5.8 Developing the Risk Response Plan: Prioritization and Resources
7 Chapter 6: System Compliance and Authorization
6.1 The Core Authorization Package & Supporting Artifacts 6.2 Plan of Action and Milestones (POA&M) Architecture & Management 6.3 System Risk Acceptance Criteria and Stakeholder Concurrence 6.4 Authorization Decision Process & Decision Types 6.5 Residual Risk Acceptance, Terms of Authorization & Continuous ATO 6.6 Documenting and Communicating the Compliance Decision
8 Chapter 7: Compliance Maintenance and Continuous Monitoring
7.1 Continuous Monitoring Strategy & Operations (NIST SP 800-137) 7.2 Configuration Management & Security Impact Analysis (NIST SP 800-128) 7.3 Incident Response and Contingency Activities in Sustained Compliance 7.4 Awareness, Training, Evidence Collection and Monitoring-Strategy Revision 7.5 Ongoing Remediation, POA&M Sustainment & Annual Reviews 7.6 Event-Driven Reauthorization & System Decommissioning
3.4 Data Handling and Marking Requirements
Key Takeaways Explain This Topic AI
Data handling and marking requirements are identified during control selection because markings must be applied at creation and persist for the life of the data.
The NARA CUI Registry under 32 CFR Part 2002 replaced the legacy agency-specific markings such as FOUO and SBU with a single government-wide category scheme.
CUI Basic follows the uniform handling rules of the CUI program, while CUI Specified follows the additional handling controls imposed by its underlying authority.
Marking obligations extend to derivative products, backups, exports, and every interconnection, which is why they are contractual requirements for external parties.
Access controls enforce who may reach data; markings communicate how it must be handled once lawfully reached, and the two are not interchangeable.
Last updated: August 2026
Data Handling and Marking Requirements
Within the control-selection task, the CGRC blueprint calls out one requirement explicitly: "Specific data handling/marking requirements identified." It sits in Domain 3 rather than in implementation or disposal for a structural reason — markings have to be applied when information is created and must survive every copy, export, and transfer thereafter. Deciding them late means unmarked copies already exist.
1. Marking and Access Control Solve Different Problems
These are routinely conflated, and the exam exploits it.
Access control answers "who is permitted to reach this data?" It is enforced by the system.
Marking answers "once someone lawfully has this data, how must they handle it?" It is enforced by the human or downstream process that reads the label.
A cleared analyst may be fully authorized to open a document — access control is satisfied. The marking is what tells them the document may not be emailed to a personal account, printed on an uncontrolled printer, or carried outside the facility. Remove markings and the authorized user has no way to know their obligations. This is why marking controls remain necessary in systems with flawless access control.
2. The CUI Program
Before 2010, agencies used dozens of incompatible labels — FOUO (For Official Use Only), SBU (Sensitive But Unclassified), LES (Law Enforcement Sensitive) — with no shared definitions, which made inter-agency sharing unreliable. Executive Order 13556 created the Controlled Unclassified Information (CUI) program to replace them with one government-wide scheme, implemented by 32 CFR Part 2002 and administered by the National Archives and Records Administration (NARA) , which publishes the authoritative CUI Registry .
The Registry organizes CUI into categories grouped into organizational index groupings, each traceable to a law, regulation, or government-wide policy (LRGWP) . This traceability requirement is the program's core discipline: information cannot be designated CUI simply because someone considers it sensitive. There must be a citable authority. Exam items describing a manager who marks a document CUI because it is "internal and embarrassing" are describing a misdesignation , not a control.
CUI Basic versus CUI Specified
CUI Basic CUI Specified
Handling rules The uniform baseline handling controls of the CUI program Additional or different controls set by the underlying authority
- Source of requirements 32 CFR Part 2002 The specific law or regulation that created the category
- Marking CUI banner CUI//SP-<category> — the SP marker signals Specified
Example General procurement-sensitive information Categories whose statutes impose specific dissemination limits
The practical rule: for Basic , apply the standard CUI handling controls. For Specified , you must read the underlying authority , because it may impose stricter destruction, dissemination, or access requirements than the CUI baseline. Treating Specified as Basic is a compliance failure.
Marking Mechanics
A CUI banner marking appears at the top and bottom of each page and includes the CUI control marking, category markings where required, and any limited dissemination control (LDC) such as NOFORN or FED ONLY , separated by double forward slashes. The designating agency is identified so recipients know whom to contact about handling questions. Portion marking — labelling individual paragraphs — is permitted and is encouraged when it helps recipients extract releasable content without over-restricting the whole document.
Important
Derivative products inherit markings. A briefing slide built from a CUI report, a spreadsheet exported from a CUI database, and a backup tape containing CUI records are all CUI and must be marked accordingly. The most common real-world failure is an analytics or reporting layer that reads from a marked source and emits unmarked outputs.
3. Implementing Handling and Marking in SP 800-53
- Control Purpose
- MP-3 (Media Marking) Mark physical and digital media to identify handling caveats and distribution limits
MP-4 / MP-5 (Media Storage / Transport) Store and transport controlled media with defined protections and accountability
AC-16 (Security and Privacy Attributes) Bind attributes (labels) to information as it is stored, processed, and transmitted
AC-21 (Information Sharing) Ensure sharing decisions are authorized and consistent with dissemination restrictions
- PT-2 / PT-3 Establish the authority and specific purposes for processing PII
- SI-12 (Information Management and Retention) Handle and retain information per applicable requirements
- MP-6 (Media Sanitization) Apply the sanitization method appropriate to the media and the marking
AC-16 is the control that makes automated enforcement possible. Once security and privacy attributes are bound to data as machine-readable metadata rather than merely painted onto a rendered page, downstream systems — data loss prevention, email gateways, rights management — can enforce handling rules automatically instead of relying on a human reading a banner.
4. Handling Requirements Cross Boundaries
Marking requirements do not stop at the authorization boundary, which is why they surface again in interconnection and contract governance.
Interconnections. The Interconnection Security Agreement must state what data types traverse the connection and what handling and marking obligations bind the receiving party. A partner who receives CUI over an interconnection is obliged to protect it, and that obligation must be written down rather than assumed.
Contracts. For contractors, handling obligations arrive through contract clauses. In the defense supply chain, CUI in a contract drives DFARS safeguarding requirements, NIST SP 800-171 , and CMMC Level 2 . A CGRC professional reviewing a procurement checks whether CUI will flow to the vendor and whether the contract carries the corresponding clauses — a gap here is a governance defect discovered too late to fix cheaply.
Cloud and multi-tenant environments. Handling requirements may constrain where data may reside, including data-residency and personnel-citizenship restrictions. These constraints must be validated against the provider's authorization before selection, because they can eliminate a provider outright.
Decontrolling
CUI status is not permanent. Information is decontrolled when the underlying authority no longer requires protection, when a specified decontrol date or event arrives, or through a formal decision by the designating agency. Decontrol is a deliberate, documented act — markings are struck through or removed and the decontrol action is recorded. Data does not become uncontrolled merely because it is old, and unilateral removal of markings by a recipient is a violation regardless of how stale the information appears.