Classification Guidelines

HITRUST CSF v11 07.d requires you to classify information based on value, legal requirements, sensitivity, and business criticality, then define what controls apply to each classification level. To operationalize it quickly, publish classification levels and criteria, map each level to mandatory handling controls, and prove consistent labeling, access, storage, transmission, and disposal across systems and third parties. (HITRUST CSF v11 Control Reference)

Key takeaways:

• Define classification levels, decision criteria, and required controls per level, then make them enforceable in systems and workflows. (HITRUST CSF v11 Control Reference)
• Evidence must show repeatable classification decisions and that handling controls match the assigned classification. (HITRUST CSF v11 Control Reference)
• The fastest path is a small number of levels, clear examples, and control mappings tied to real tooling (IAM, DLP, encryption, retention). (HITRUST CSF v11 Control Reference)

“Classification guidelines requirement” in HITRUST is not a paperwork exercise. Auditors want to see that your organization can (1) consistently decide what data is, (2) assign it a classification level using defined criteria, and (3) apply the right protections for that level across the data lifecycle. HITRUST CSF v11 07.d is explicit: classification must account for value, legal requirements, sensitivity, and criticality, and you must establish both the levels and the controls required at each level. (HITRUST CSF v11 Control Reference)

For a CCO or GRC lead, the operational challenge is alignment: Legal cares about regulatory obligations, Security cares about technical safeguards, Engineering cares about what is feasible in platforms, and the business cares about speed. This requirement page gives you a working approach: a simple classification model, a control mapping you can attach to standards, and the minimum evidence set to satisfy assessment scrutiny. It also flags the common traps (too many levels, unclear ownership, “classified” data that is not protected) that create audit findings and real exposure.

Regulatory text

Requirement (quoted): “Information shall be classified in terms of its value, legal requirements, sensitivity, and criticality to the organization. A classification system shall be established with defined levels, criteria for classification, and the controls required at each classification level.” (HITRUST CSF v11 Control Reference)

What the operator must do:
You must implement a documented, repeatable classification system with:

1. Defined levels (for example, Public / Internal / Confidential / Restricted),
2. Defined criteria to decide the level (value, legal obligations, sensitivity, criticality), and
3. Defined controls required for each level (how data is labeled, accessed, stored, transmitted, logged, retained, and disposed). (HITRUST CSF v11 Control Reference)

Plain-English interpretation

You need a common language for information risk that the business and technical teams can execute. Classification tells people and systems what protections are mandatory. If you cannot explain “what counts as Restricted and what we do differently,” you are not meeting the requirement. (HITRUST CSF v11 Control Reference)

A strong implementation has two properties:

• Decision clarity: Two different teams classify the same dataset the same way because the criteria and examples are unambiguous.
• Control enforcement: The assigned classification changes real controls (encryption requirements, access approvals, DLP rules, retention, third-party sharing rules). (HITRUST CSF v11 Control Reference)

Who it applies to

Entity scope: All organizations adopting HITRUST CSF v11. (HITRUST CSF v11 Control Reference)

Operational scope (where it must work):

• Data in systems you run: endpoints, servers, cloud workloads, SaaS, databases, data lakes, collaboration tools.
• Data in motion: email, APIs, file transfers, messaging, removable media.
• Data handled by third parties: hosting providers, SaaS processors, billing partners, support tooling, consultants who access or store your data.
• Data artifacts: reports, exports, logs, screenshots, backups, analytics extracts, training datasets.

If your organization touches regulated health information or other sensitive data, classification must connect to the “legal requirements” criterion in a way staff can apply consistently. (HITRUST CSF v11 Control Reference)

What you actually need to do (step-by-step)

1) Establish ownership and scope boundaries

• Assign a policy owner (often Security/GRC) and a business approver (data governance leader, Privacy, or Legal).
• Define what “information” covers in your environment: customer data, employee data, IP, financials, security secrets, and operational data.
• Decide what you will classify first: start with the datasets that create the most exposure (customer records, clinical/health data, authentication secrets, financial reporting). (HITRUST CSF v11 Control Reference)

2) Define classification levels (keep it small and executable)

Create a short list of levels with names that can be put into tools and training. A workable pattern:

Level	Typical meaning	Typical sharing rule
Public	Approved for public release	May be shared externally without approval
Internal	Non-public business info	Share internally; external sharing needs approval
Confidential	Sensitive business or personal data	Need-to-know access; controlled external sharing
Restricted	Highest sensitivity/impact	Strict access, strong encryption, audited sharing only

This table is guidance; HITRUST requires defined levels but does not prescribe the names. Your key deliverable is that these levels exist and are used consistently. (HITRUST CSF v11 Control Reference)

3) Write criteria that map to HITRUST’s four factors

Your criteria must explicitly cover:

• Value: Would disclosure harm competitiveness or trust?
• Legal requirements: Does a law/contract require special handling or breach notification?
• Sensitivity: Could exposure cause harm to individuals, customers, or security?
• Criticality: Would loss/unavailability disrupt operations or patient care?

Operationalize this as a decision tree your teams can follow. Example prompts:

• Does the dataset contain sensitive personal data or regulated health information?
• Would unauthorized modification create safety, clinical, or financial reporting risk?
• Would downtime block a critical business process?

Document “if/then” outcomes with examples. Auditors look for criteria that produce consistent decisions, not long narrative text. (HITRUST CSF v11 Control Reference)

4) Map each classification level to mandatory controls

This is where programs fail: they define levels but do not attach enforceable controls. Build a “control-by-classification” matrix and link it to standards and technical baselines.

Minimum control categories to map:

• Labeling/marking: file headers, email banners, metadata tags.
• Access control: least privilege, approval workflow for Restricted access, periodic reviews.
• Storage security: encryption requirements, approved repositories, restrictions on local storage.
• Transmission security: encryption in transit, approved transfer methods, blocking insecure channels.
• Logging/monitoring: audit logging for access to Restricted; alerting for suspicious exfiltration.
• Retention/disposal: retention rules, secure deletion/destruction.
• Third-party sharing: due diligence, contract clauses, and restrictions based on classification. (HITRUST CSF v11 Control Reference)

Make the mapping specific enough that IT can implement guardrails. For example: “Restricted data must only be stored in approved systems with strong access controls and encryption enabled” is actionable because you can define the approved systems list and verify encryption settings. (HITRUST CSF v11 Control Reference)

5) Embed classification into workflows people already use

Do not rely on employees remembering a PDF.

High-yield integration points:

• Data inventory / data catalog: require a classification field for each dataset and each key data element where feasible.
• Access requests: require classification selection; route approvals based on level.
• SDLC: require classification for new tables/objects and for exported datasets.
• Procurement and third-party onboarding: require the highest classification a third party will receive/process; drive security review depth and contractual controls from that.
• Incident response: triage severity based on classification and impacted systems.
• Training: short, role-based examples (“Support can email Internal; cannot email Restricted”). (HITRUST CSF v11 Control Reference)

If you use Daydream to run third-party risk workflows, capture “data classification shared” as a required intake field and automatically trigger stronger diligence for Restricted data (security questionnaire depth, contract addenda, and evidence requests). Keep the classification-to-control mapping in the same workflow so decisions are consistent across departments.

6) Validate and test (prove it works)

Run a practical test:

• Pick representative datasets from each major system (HR, customer app, analytics, support tickets).
• Verify the documented classification matches reality (data elements, sensitivity, legal obligations).
• Confirm required controls are in place (permissions, encryption settings, sharing pathways).
• Sample third-party relationships and confirm contracts and access align with the classification shared. (HITRUST CSF v11 Control Reference)

Required evidence and artifacts to retain

Auditors typically expect a chain from policy to practice. Keep artifacts that show both design and operation.

Core documents

• Information Classification Policy/Standard with levels, definitions, and criteria. (HITRUST CSF v11 Control Reference)
• Control-by-classification matrix (handling requirements per level). (HITRUST CSF v11 Control Reference)
• Data handling procedures (storage, transmission, disposal) aligned to classification. (HITRUST CSF v11 Control Reference)

Operational records

• Data inventory or catalog exports showing classification fields populated for key datasets.
• Samples of labeled documents/emails or system tags demonstrating labeling conventions.
• Access review evidence for repositories containing Confidential/Restricted data.
• Encryption configuration evidence for systems storing higher-classification data.
• Third-party records: intake forms identifying classification shared; contracts or addenda reflecting required controls; due diligence outputs tied to classification. (HITRUST CSF v11 Control Reference)

Governance

• Exception register: approved deviations, compensating controls, time bounds, owners.
• Training records and quick-reference guidance distributed to staff. (HITRUST CSF v11 Control Reference)

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me your classification levels, criteria, and the handling controls per level.” (HITRUST CSF v11 Control Reference)
• “How do you ensure staff classify information consistently?”
• “Where is classification captured for key systems and datasets?”
• “Demonstrate that Restricted data is actually protected differently than Internal.”
• “How do you control sharing of Confidential/Restricted data with third parties?” (HITRUST CSF v11 Control Reference)

Hangups that create findings:

• Classification exists only in a policy, not in tools.
• Teams interpret levels differently because criteria are subjective.
• No evidence that controls vary by classification. (HITRUST CSF v11 Control Reference)

Frequent implementation mistakes and how to avoid them

1. Too many classification levels.
   Fix: keep levels few and trainable; add nuance via handling rules and examples.

2. Confusing data type with classification.
   Fix: treat data type (PHI, credentials, financials) as an input to classification, not the classification itself.

3. No control mapping.
   Fix: publish a matrix that forces differences in access, storage, transmission, and third-party sharing. (HITRUST CSF v11 Control Reference)

4. No owner for decisions.
   Fix: assign dataset owners; make classification a required field in data intake and change management.

5. Unmanaged exceptions.
   Fix: formalize exceptions with compensating controls, expiry, and review cadence.

Risk implications (why auditors care)

Misclassification drives two common failure modes:

• Under-classification: sensitive data gets weak controls, leading to unauthorized access, oversharing, or weak third-party handling.
• Over-classification: staff route around controls, store data in shadow IT, or stop classifying altogether.

HITRUST frames classification around value, legal requirements, sensitivity, and criticality because those dimensions map directly to business impact and regulatory exposure. Your program should let you show that the highest-risk information has the strongest, consistently applied controls. (HITRUST CSF v11 Control Reference)

A practical 30/60/90-day execution plan

First 30 days (foundation and fast alignment)

• Assign owners and approvers for the classification standard. (HITRUST CSF v11 Control Reference)
• Draft classification levels and criteria; include concrete examples for top business systems.
• Build the control-by-classification matrix for access, storage, transmission, logging, retention, disposal, and third-party sharing.
• Identify the initial dataset list to classify (start with core systems and major third-party data flows).

Days 31–60 (embed into operations)

• Add classification fields to the data inventory/catalog and require completion for in-scope datasets.
• Update access request workflows to capture classification and route approvals accordingly.
• Update third-party onboarding to record the highest classification shared and trigger due diligence depth based on it.
• Publish a one-page “How to classify” guide and run targeted training for data owners and system admins. (HITRUST CSF v11 Control Reference)

Days 61–90 (prove operating effectiveness)

• Perform sampling: verify classification correctness and control implementation across representative systems.
• Execute an access review for repositories storing Confidential/Restricted data; remediate gaps.
• Review third-party contracts and security controls where Restricted data is shared; document remediation plans or exceptions.
• Finalize an exception register and governance cadence so classification decisions stay current as systems and data change. (HITRUST CSF v11 Control Reference)

Frequently Asked Questions

Do we have to classify every single file and email to meet HITRUST 07.d?

HITRUST requires a classification system with defined levels, criteria, and controls, plus evidence it operates in practice. Most teams start with datasets and systems, then expand labeling and automation where it reduces risk and improves consistency. (HITRUST CSF v11 Control Reference)

How many classification levels should we have?

HITRUST does not mandate a number; it mandates that levels, criteria, and controls are defined. Use as few as you can while still driving meaningful control differences between levels. (HITRUST CSF v11 Control Reference)

What’s the difference between “sensitivity” and “criticality” in the criteria?

Sensitivity is about harm from unauthorized disclosure or modification. Criticality is about business impact if the information is unavailable or corrupted during operations. Both must be reflected in your classification criteria. (HITRUST CSF v11 Control Reference)

How do we operationalize classification for third parties?

Record the highest classification a third party will access, process, or store, and bind required controls to that level through due diligence and contract terms. Keep evidence that the classification drove review depth and safeguards. (HITRUST CSF v11 Control Reference)

What evidence is most persuasive in an assessment?

A control-by-classification matrix plus system-level proof (permissions, encryption settings, logging) tied to classified datasets is typically stronger than policy text alone. Add samples showing labeling/tags and third-party records that reflect the same classification decisions. (HITRUST CSF v11 Control Reference)

What if a business unit disagrees with the assigned classification?

Treat disagreements as governance events: document the rationale, require a formal exception if they want lower controls, and assign an accountable owner with compensating controls and an expiration for re-review. (HITRUST CSF v11 Control Reference)