Data Labeling by Sensitivity and Impact

Why This Topic Matters
In the ISC2 CSSLP, Domain 2 (Secure Software Requirements) emphasizes that you cannot protect what you have not identified and classified. Data labeling by sensitivity and impact is the bridge between abstract security policy and concrete software requirements. If a developer does not know that a field holds Protected Health Information (PHI) or a payment card number, they cannot apply the right encryption, access control, logging, or retention rules. Mislabeling or failing to label data leads to over-protection (wasted cost and friction) or under-protection (breaches, regulatory fines, loss of trust). On the exam, this topic appears in questions about requirements gathering, data classification schemes, regulatory compliance (GDPR, HIPAA, PCI DSS), and how classification drives the selection of security controls.

What It Is
Data labeling by sensitivity and impact is the process of categorizing data according to two related dimensions:
1. Sensitivity – how confidential the data is and who is authorized to see or modify it (e.g., Public, Internal, Confidential, Restricted/Top Secret).
2. Impact – the degree of harm to the organization, individuals, or third parties if the confidentiality, integrity, or availability of that data is compromised (e.g., Low, Moderate, High, as in FIPS 199 / NIST SP 800-60).

The label is the tag or marking applied to the data (in metadata, headers, database columns, documents, or data flow diagrams) so that people and systems can recognize its classification and handle it consistently. In software development, labeling is captured as a security requirement: "The application shall classify customer SSNs as Restricted and encrypt them at rest using AES-256."

Key Concepts and Terminology
- Data Classification Scheme: The organization's defined set of categories (e.g., commercial: Public / Internal / Confidential / Restricted; government: Unclassified / Confidential / Secret / Top Secret).
- Data Owner: The business role accountable for deciding the classification. Not the developer, not the DBA, not the security team. The owner determines the label; custodians implement protections.
- Data Custodian: Implements and maintains controls (encryption, backups, access) as directed by the owner.
- CIA Impact: Impact is assessed separately for Confidentiality, Integrity, and Availability. Publicly available stock prices have low confidentiality impact but high integrity impact.
- High-Water Mark: When a system processes multiple data types, the system's overall classification is set by the most sensitive/highest-impact data it handles (FIPS 199 principle).
- Structured vs. Unstructured Data: Databases are easier to label at the column level; documents, emails, and logs are harder and often need DLP tools or manual marking.
- Data Lifecycle: Labels govern handling at every stage – creation, storage, use, sharing, archival, and destruction.
- Regulatory Drivers: PII (GDPR, CCPA), PHI (HIPAA), Cardholder Data (PCI DSS), Export-controlled data (ITAR/EAR), Financial data (SOX, GLBA).
- Declassification/Reclassification: Labels can change over time; e.g., an earnings report is Restricted before release and Public after.

How It Works in the Secure SDLC
Step 1 – Identify data elements. During requirements gathering, list every data type the application will create, process, store, or transmit. Data flow diagrams (DFDs) are the primary tool.
Step 2 – Determine sensitivity. The data owner assigns a sensitivity category based on policy, regulations, contractual obligations, and business value.
Step 3 – Assess impact. For each data element, ask: what is the worst-case consequence if this is disclosed (C), altered (I), or unavailable (A)? Rate each as Low/Moderate/High. Consider financial loss, legal penalties, reputational harm, safety, and privacy harm to individuals.
Step 4 – Apply the label. Record the classification in the requirements documentation, data dictionary, database schema (column-level tags), API specifications, and in system metadata where possible.
Step 5 – Derive security requirements. Each label maps to a predefined set of controls. Example mapping:
- Public: integrity protection (digital signatures/hashes), no confidentiality controls needed.
- Internal: authentication required, basic access control, TLS in transit.
- Confidential: role-based access control, encryption in transit and at rest, audit logging.
- Restricted: strong encryption with managed keys, MFA, field-level encryption or tokenization, data masking in non-production, strict retention and secure deletion, DLP monitoring.
Step 6 – Carry labels forward. Labels inform threat modeling (Domain 3), secure coding choices (Domain 4), test data handling (Domain 5), deployment configuration (Domain 6), and supply chain contracts (Domain 8).
Step 7 – Review and maintain. Reclassify when business context or regulations change; include classification review in change management.

Relationship to Related Concepts
- Privacy Requirements: Labeling PII enables data minimization, consent tracking, and the right to erasure.
- Least Privilege and Need-to-Know: Labels define who legitimately needs access.
- Mandatory Access Control (MAC): In high-security systems, labels on data and clearances on subjects are enforced by the system (Bell-LaPadula for confidentiality, Biba for integrity).
- Data Loss Prevention (DLP): Relies on labels to detect and block unauthorized exfiltration.
- Risk Management: Impact ratings feed directly into risk calculations (Risk = Likelihood x Impact).

Common Pitfalls
- Letting developers or IT decide classification instead of the data owner.
- Having too many categories (unusable) or too few (meaningless). Three to five levels is typical.
- Classifying only on confidentiality while ignoring integrity and availability impact.
- Labeling at design but losing labels when data is copied to logs, caches, backups, reports, or test environments.
- Treating aggregated data as low sensitivity when the combination is actually highly sensitive (the aggregation problem).
- Over-classifying everything as Restricted, which drives up cost and leads to workarounds.

Exam Tips: Answering Questions on Data Labeling by Sensitivity and Impact
1. Who classifies? If the question asks who is responsible for determining the classification of data, the answer is almost always the data owner (business owner), not the developer, security officer, or custodian. The custodian implements; the owner decides.
2. Why classify? If asked for the primary purpose, choose answers about applying appropriate (cost-effective, proportional) controls based on value and risk, not about compliance alone or about making all data secure.
3. Think CIA, not just C. When a question describes data such as medical dosage values, financial ledgers, or control system setpoints, recognize that integrity or availability impact may be the dominant concern. Do not default to confidentiality.
4. Highest classification wins. When a system or record contains mixed data, the high-water mark applies: protect to the level of the most sensitive element.
5. Requirements phase placement. CSSLP wants you to know classification happens early, during requirements gathering, and drives downstream decisions. If an answer suggests classifying data during testing or after deployment, it is likely wrong.
6. Recognize regulated data types. Be able to identify PII, PHI, PCI cardholder data, and PFI (personal financial information) and know these automatically require elevated classification and specific regulatory controls.
7. Map labels to controls. Expect scenario questions: "Data is classified Restricted; which requirement is MOST appropriate?" Choose the strongest proportional control (encryption at rest and in transit, strict access control, audit logging), not weaker ones like "inform users of policy."
8. Watch for aggregation and inference. If individually harmless data elements combine into something sensitive, the correct answer recognizes the aggregate requires higher classification.
9. Labels must persist. Questions about test environments, backups, or logs test whether you understand that classification follows the data wherever it goes; test data should be masked or synthetic if production data is Confidential or higher.
10. Beware of extremes. Answers like "classify all data as Top Secret" or "encrypt everything regardless of classification" are distractors; CSSLP favors risk-based, proportional approaches.
11. Eliminate role confusion. Distinguish data owner (accountable, classifies), data custodian (implements controls), data steward (quality and governance), and user (handles per policy).
12. Use the BEST/MOST/FIRST keywords. When asked what should be done FIRST in a data protection effort, the answer is typically identify and classify the data, because everything else depends on it.

Sample Question Walkthrough
A development team is building an HR application that stores employee names, office phone extensions, salary data, and Social Security Numbers. During requirements gathering, what is the MOST appropriate action?
A) Encrypt the entire database with a single key.
B) Have the data owner classify each data element and derive protection requirements per classification.
C) Classify all fields as Public since they are internal to the company.
D) Defer classification until the testing phase when data flows are clearer.

Answer: B. Classification is the data owner's responsibility, occurs during requirements, and should be granular enough that salary and SSNs (Restricted) receive stronger controls than phone extensions (Internal). Option A is a blanket control not driven by classification, C under-protects, and D is too late in the SDLC.

Quick Recap
- Data labeling assigns a sensitivity level and an impact rating (per C, I, and A) to every data element.
- The data owner decides; custodians implement.
- Labels drive proportional security requirements and persist through the data lifecycle.
- Classify early, apply the high-water mark, consider aggregation, and avoid one-size-fits-all answers on the exam.