Why Data Type Matters for Security
Data is one of the most valuable assets an organization owns — but not all data is equally sensitive, equally regulated, or equally at risk. A security model that treats all data identically is both operationally unworkable (too restrictive for low-risk data) and inadequate (not protective enough for high-risk data). Understanding what type of data you are working with is the prerequisite for every other data security decision: which controls to apply, who can access it, how long to keep it, and what happens if it is exposed.
The exam distinguishes several fundamental categories of data. Each category has distinct characteristics and security implications.
Regulated Data
Regulated data is any data whose handling is governed by an external authority — a government, regulatory body, or industry standards organization — rather than solely by the organization that holds it. The organization does not get to decide how to protect this data; the rules are imposed from outside.
Common regulatory frameworks that define regulated data:
- Payment Card Industry Data Security Standard (PCI DSS): Governs credit card data — cardholder names, card numbers, expiration dates, CVVs. Any organization that stores, processes, or transmits payment card data must comply with PCI DSS requirements for encryption, access control, and network segmentation.
- HIPAA (Health Insurance Portability and Accountability Act): Governs Protected Health Information (PHI) in the United States — medical records, treatment histories, health insurance information. Healthcare providers, insurers, and their business associates must comply.
- GDPR (General Data Protection Regulation): European Union regulation governing personal data of EU residents — applies to any organization worldwide that handles EU personal data.
- Government laws and statutes: Various national and local laws dictate retention periods, access rights, cross-border transfer restrictions, and mandatory breach notification requirements.
The critical characteristic of regulated data: a third party defines the security requirements. Non-compliance carries legal penalties, financial fines, and potential loss of operating licenses. The organization bears responsibility for compliance even if the data breach is caused by a third-party vendor.
Trade Secrets
Trade secrets are confidential organizational assets whose value comes entirely from remaining secret. Unlike intellectual property protected by registered legal rights (patents, copyrights), trade secrets have no registration mechanism — protection depends entirely on keeping the information confidential.
Examples of trade secrets:
- Manufacturing processes or formulas (the classic example: a beverage formula, pharmaceutical synthesis process)
- Internal pricing models and business strategies
- Proprietary algorithms and software architectures
- Customer lists and acquisition strategies
- Internal methodologies that give competitive advantage
The security implication: trade secrets derive their value from being unknown to competitors. Once exposed, the value is permanently lost — you cannot "un-disclose" a formula. This makes trade secret protection a confidentiality-first problem. Insider threat is a primary risk vector because employees with legitimate access may exfiltrate trade secrets to competitors or for personal gain.
Intellectual Property
Intellectual property (IP) is different from trade secrets in a fundamental way: IP can be publicly visible while still being legally protected. A published novel is fully readable by anyone — but it is protected from unauthorized reproduction by copyright law. A product logo is visible on every package — but it is protected from imitation by trademark registration.
Forms of intellectual property and their protection mechanisms:
- Copyright: Protects original works of authorship — software code, written content, artistic works. Automatic upon creation; no registration required in most jurisdictions. Prohibits unauthorized copying, distribution, and derivative works.
- Trademark: Protects brand identifiers — names, logos, slogans. Registered with government trademark offices. Prohibits use of confusingly similar marks by competitors.
- Patent: Protects inventions and innovations. Requires registration and public disclosure of the invention in exchange for exclusive rights for a defined period.
Security implication: IP protection is primarily a legal enforcement matter rather than an access control problem. The content may be publicly viewable, but unauthorized use violates legal rights. Security controls on IP focus on preventing unauthorized copying, distribution, and use — DRM (digital rights management), watermarking, and monitoring for unauthorized reproduction.
Legal Information
Legal information includes data generated or maintained in the context of legal proceedings and professional legal activities: court records, case files, attorney communications, judicial decisions, and legal research. This category has a unique dual nature.
On one hand, many legal records are public by design — court decisions, docketed cases, and public legal filings are intentionally accessible to maintain transparency in the justice system. On the other hand, legal proceedings frequently contain highly sensitive personal information: victims' names and contact details, witnesses' identities, personal financial disclosures, medical information introduced as evidence, and attorney-client privileged communications.
The security challenge: legal systems typically distribute records across multiple storage systems — public docket systems (accessible to anyone), court management systems (accessible to court staff), sealed records systems (restricted by court order), and attorney work product repositories (attorney-client privilege). Security controls must enforce these different access tiers consistently, often across legacy systems that were not designed with modern security models in mind.
Financial Information
Financial data encompasses two distinct scopes that require different security treatment:
- Internal company financial data: Revenue figures, profit margins, budget plans, acquisition targets, financial projections, and executive compensation. This information, if leaked to competitors or the market prematurely, can cause significant competitive harm or violate securities regulations.
- Customer financial data: Bank account numbers, credit card information, payment records, purchase histories, and credit scores. This data is typically regulated (PCI DSS, bank secrecy laws) and is a primary target for attackers because it has direct monetary value. A credit card number can be immediately monetized; a bank account number enables direct theft.
Financial data breaches are among the most costly and most frequent. The combination of regulatory requirements, direct monetary value to attackers, and reputational damage makes financial data one of the highest-priority data types for protection.
Human-Readable vs. Non-Human-Readable Data
Beyond the content category of data, the exam also tests understanding of the format dimension — whether a human can directly interpret the data without processing tools.
Human-readable data can be understood by anyone who reads it without special tools — plain text documents, emails, reports, word processing files, spreadsheets. The security implication is straightforward: if this data is exposed (visible on a screen, printed and left on a desk, sent to the wrong recipient), a human immediately understands what they are looking at. A plain-text document containing passwords is instantly compromised when seen.
Non-human-readable data is encoded, compressed, or structured in ways that require specialized tools or systems to interpret. Examples:
- Barcodes and QR codes (encode data visually, not readable without a scanner)
- Binary executable files (contain instructions and data in binary format)
- Encrypted data (ciphertext — requires decryption key)
- Machine-generated data streams (network packet captures, sensor telemetry)
The security implication of non-human-readable data: it is not necessarily safer simply because a human cannot immediately read it. A barcode still encodes specific data values. An encrypted file still contains the original sensitive data — it just requires a key to access. The format does not eliminate the security requirement; it changes how the data must be protected.
Hybrid formats are an important middle ground — formats that are interpretable by both humans and machines but require some familiarity to read directly. Key examples:
- CSV (Comma-Separated Values): A text file where fields are separated by commas — readable by humans who understand the format, parseable by software
- XML (Extensible Markup Language): Tagged data format used for configuration files, APIs, and data exchange — human-readable but verbose
- JSON (JavaScript Object Notation): Lightweight data interchange format used extensively in APIs and web applications — human-readable, widely used for system integration
Hybrid formats are particularly common in data exchange and system integration scenarios — making them frequent targets in security incidents. A CSV file exported from an HR system might contain names, SSNs, and salary data in a format that is completely readable in any text editor. JSON API responses frequently contain PII or authentication tokens. Security controls for hybrid formats must account for both their machine-processability (which systems can receive them?) and their human-readability (who can open them in a text editor?).
Why Classification Precedes Security Controls
Classification is the process of assigning a category to data based on its sensitivity, ownership, and the potential harm that could result from its unauthorized disclosure or loss. Before you can decide what controls to apply, you must know what you are protecting and why. Classification answers that question systematically across an organization's data holdings.
Without classification, organizations face two failure modes: over-protecting low-sensitivity data (wasting resources, creating friction) or under-protecting high-sensitivity data (creating risk, enabling breaches). Classification calibrates protection to match actual sensitivity.
Proprietary Data
Proprietary data is any information that belongs exclusively to the organization — created by the organization, owned by the organization, and not publicly available. The defining characteristic: this data provides value precisely because it is not available outside the organization.
Proprietary data includes:
- Internal business processes and operational methods
- Trade secrets (the most sensitive subset of proprietary data)
- Proprietary software, algorithms, and technical specifications
- Internal research and development findings
- Business strategies, competitive analyses, and pricing models
- Customer lists and supplier relationships
The security model for proprietary data is primarily confidentiality-focused — prevent unauthorized disclosure. Insider threat is the primary risk vector because employees have the access and context to identify and exfiltrate valuable proprietary information. Data loss prevention (DLP) systems, employee monitoring, and strict access controls on the most sensitive proprietary assets are standard controls.
Note that "proprietary" as a classification label is distinct from the general adjective use of the word. When used as a data classification, "Proprietary" indicates that this data belongs to the organization and should not be disclosed outside — roughly equivalent to "internal use only" or "company confidential."
PII — Personally Identifiable Information
Personally Identifiable Information (PII) is any data that can be used — alone or in combination with other information — to identify a specific individual. PII is the central concept in most privacy regulations worldwide, and its definition has expanded significantly as digital data enables increasingly precise identification.
Direct identifiers — single data points that identify an individual on their own:
- Full legal name
- Social Security Number (SSN) or national identification number
- Passport number
- Driver's license number
- Biometric data (fingerprints, retinal scans, facial recognition data, DNA)
- Email address (when associated with a named person)
- Phone number
Indirect identifiers — data that can identify an individual when combined with other information:
- Date of birth + gender + ZIP code (this combination alone identifies most individuals)
- Physical address
- Mother's maiden name (commonly used as a security question)
- Racial or ethnic origin
- IP address (in many jurisdictions)
- Device identifiers and persistent cookies
The combination problem: individually innocuous data points can become PII when aggregated. A name alone is not sensitive. A ZIP code alone is not sensitive. Date of birth alone is not sensitive. But name + ZIP code + date of birth + employer is enough to identify and locate most individuals with high confidence. This aggregation risk means data that appears non-sensitive when viewed in isolation may require protection when stored alongside other fields.
Regulatory significance: PII is the primary subject of privacy laws — GDPR, CCPA (California Consumer Privacy Act), COPPA (children's online privacy), and many sector-specific regulations. Organizations that collect, store, process, or transfer PII must comply with applicable privacy regulations or face substantial financial penalties and legal liability.
PHI — Protected Health Information
Protected Health Information (PHI) is a specific, legally defined category in the United States under HIPAA (Health Insurance Portability and Accountability Act). PHI is health information that is associated with an individual and created, received, maintained, or transmitted by a covered entity (healthcare provider, health plan, or healthcare clearinghouse) or their business associates.
PHI includes:
- Medical diagnoses and treatment records
- Prescription records and medication history
- Laboratory test results
- Mental health records
- Health insurance enrollment information and claims
- Payments made for healthcare services (the financial record becomes PHI when linked to health care)
- Any identifiers that connect the above to a specific individual (name, address, DOB, SSN, account numbers, etc.)
PHI vs. PII — the critical distinction: PII is any individually identifying information regardless of context. PHI is specifically health-related information combined with individual identifiers — it is a type of PII, but narrower and more specifically regulated. A person's name is PII. A person's name combined with their diagnosis and treatment records is PHI. The security requirements for PHI are more stringent and more specifically defined than for general PII.
HIPAA requirements for PHI include: access controls, audit controls (logging all access to PHI), integrity controls, transmission security (encryption in transit), physical safeguards, administrative safeguards (workforce training, business associate agreements), and mandatory breach notification to affected individuals and HHS (Health and Human Services) within specified timeframes.
The scope of PHI is broader than most people expect: payment records for healthcare services are PHI even though they appear to be financial data. An appointment scheduling record is PHI because it indicates that a person received (or sought) healthcare services. A photograph taken during a clinical encounter is PHI. The test for PHI: is this health-related information that can be connected to an identifiable individual?
The Classification Spectrum
Once data has been categorized by type (what kind of data it is) and classification (whose data it is — proprietary, PII, PHI), the next step is assigning a sensitivity level. Sensitivity levels determine the practical access and handling rules for the data: who can see it, under what circumstances, and what protections must be in place.
The five classification levels span from completely open to highly restricted, with each level carrying progressively more stringent access and handling requirements.
Sensitive
The "sensitive" classification covers data that requires controlled handling due to the harm that could result from unauthorized disclosure, but is not so restricted that access requires formal approval processes. Typical contents: intellectual property, PII, PHI, and internal proprietary data.
Security controls for sensitive data:
- Access limited to employees with a need-to-know
- Encryption required for storage and transmission
- Access monitoring and audit logging
- Cannot be shared outside the organization without authorization
- Covered by data loss prevention (DLP) policies
This is the baseline "non-public" classification — the default for most internal business data that should not leave the organization.
Confidential
Confidential data is more sensitive than the general "sensitive" category and requires explicit authorization before access is granted. The bar for access is higher: users do not receive access by default based on job function; they must be specifically approved.
Typical confidential data:
- Executive communications and board materials
- Legal negotiations and settlement discussions
- M&A (merger and acquisition) planning documents
- Strategic plans and competitive analysis
- Detailed financial models and unreleased financial results
Security controls for confidential data:
- Explicit individual authorization required for each access grant
- Stronger encryption standards
- More granular audit logging
- May require physical security controls (locked storage, clean-desk policies)
- Often restricted to specific systems or rooms within the organization
Public / Unclassified
Public or unclassified data is information with no viewing restrictions — it can be freely shared with anyone and is intended for broad distribution. This is not the absence of security; it is a deliberate classification that says "this data is safe to be public."
Examples: marketing materials, published press releases, public websites, published research reports, public-facing product documentation, open job postings.
Important nuance: even public data may require integrity protection. A public website does not need confidentiality controls (anyone can read it), but it does need integrity controls (no one should be able to alter the content without authorization). Defacing a public website or injecting malicious content into public pages is an attack on integrity, not confidentiality.
In government contexts, "unclassified" has a specific meaning — it is the baseline tier of the government classification system, sitting below Confidential, Secret, and Top Secret. Unclassified government information may be further divided into CUI (Controlled Unclassified Information) — unclassified but requiring handling controls — and publicly releasable information.
Private / Classified / Restricted
These terms are often used interchangeably across different organizations and sectors to describe data that requires restricted access — more controlled than "sensitive" but the distinction from "confidential" varies by organizational policy. The key characteristics:
- Access control: Not available to general employees — requires explicit authorization and often formal vetting
- Legal agreements: Access may require signing a non-disclosure agreement (NDA) or confidentiality agreement — particularly for contractors and external parties who need access
- Need-to-know enforcement: Even within the authorized group, access is further restricted based on specific need
- Government classified data: In government contexts, "classified" has specific legal meaning — Confidential, Secret, and Top Secret are formal classification levels with legal requirements and criminal penalties for unauthorized disclosure. Security clearances are required to access classified government data.
Examples: government intelligence reports, corporate trade secrets, pre-announcement financial results, sensitive merger planning, personal financial records held by financial institutions.
Critical
The "critical" classification is unique because it is primarily about availability rather than confidentiality. Critical data is data that must remain continuously accessible for the organization to function. Loss of access to critical data — even temporarily — causes immediate operational disruption.
Examples:
- Operational databases that systems query in real time (transaction databases, inventory systems)
- Infrastructure management systems (DNS, authentication systems, monitoring platforms)
- Emergency communication and dispatch systems
- Medical systems where inaccessibility could harm patients
- Financial trading systems where downtime has direct monetary cost
Security focus for critical data: the primary control is availability — backup and recovery systems, high availability architectures (redundancy, clustering, failover), tested disaster recovery procedures, and SLA monitoring. Critical data may also need confidentiality and integrity protections, but availability is the classification driver.
The exam frequently tests this distinction: critical data = availability concern. This is different from the other four levels, which are all primarily about access control (confidentiality). If a question asks about classification levels and describes a scenario where the concern is "what happens if this data is unavailable" — the answer is critical data classification.
How Classification Drives Security Architecture
Classification does not exist in isolation — it directly determines what security controls are deployed:
- Access controls: Role-based access control (RBAC) policies reference classification labels to determine who can access what. A user account in the "general employees" role might have access to sensitive and public data but not confidential or restricted.
- Network segmentation: Critical and restricted data may be stored in isolated network segments — VLANs or air-gapped systems — where only specifically authorized systems and users can reach the storage. The exam describes this as a "restricted area of the network."
- Encryption standards: Higher classification levels typically require stronger encryption — both at rest and in transit. Publicly accessible data may not require encryption; confidential and restricted data always does.
- Data Loss Prevention (DLP): DLP systems use classification labels to detect and block unauthorized transfer of sensitive, confidential, or restricted data. A DLP policy might allow "public" content to be emailed but block emails containing text matching PII patterns (SSNs, credit card numbers) without encryption.
- Retention policies: Classification influences how long data must be retained and how it must be disposed of. Regulated data may have mandatory retention periods; classified data requires certified destruction.