Information Classification Assessment Template – Free Word Download

Information Classification Assessment Template – Free Word Download – Copy and Paste Wording Below

Introduction

In the realm of project management and information security, not all data is created equal. The Information Classification Assessment is a vital governance tool designed to categorize data based on its sensitivity, value, and criticality to the organization. Without a formal classification process, organizations often default to a “one-size-fits-all” security model. This approach is inefficient and risky. It can lead to over-spending on protecting public data or, far worse, under-protecting critical intellectual property or customer records.

This template provides a structured methodology for Project Managers, Data Owners, and Information Security Officers to evaluate the information assets associated with a specific project. By assigning a classification level to each data set, the project team can determine the appropriate handling, storage, and access controls required. This ensures that security measures are commensurate with the risk. For example, a project involving the company cafeteria menu requires significantly fewer safeguards than a project handling employee payroll data.

Completing this assessment is a prerequisite for defining technical requirements. It informs the architecture, the choice of vendors, the design of user interfaces, and the drafting of legal contracts. This document guides you through defining your data, assessing the impact of a potential breach, and establishing the “rules of the road” for how that information must be treated throughout its lifecycle.

Section 1: Assessment Overview and Ownership

1.1 Project Metadata

Instructions:

This section establishes the administrative context. It links the data classification to a specific business initiative. This is crucial for auditing purposes; if a data breach occurs, investigators will look for this document to see if the data was correctly classified at the project’s inception.

  • Project Name: [Enter official project name]
  • Project ID: [Enter unique identifier]
  • Assessment Date: [Date of completion]
  • Review Date: [Date for future review, typically annually]
  • Project Manager: [Name and Contact]
  • Data Owner: [Name of the senior executive responsible for the data]
  • Data Steward: [Name of the operational lead managing the data]

Guidance on Roles:

  • Data Owner: Usually a VP or Director. They have the ultimate authority to say “yes” or “no” to how data is used. They are accountable for the risk.
  • Data Steward: The functional expert who understands the data’s structure and quality (e.g., a Database Administrator or Business Analyst).

1.2 Scope of Assessment

Instructions:

Define what this assessment covers. Does it cover the entire new CRM system? Just the migration phase? Or perhaps a specific module being added to an existing app?

Example:

“This assessment covers all data created, processed, stored, or transmitted by the new ‘Global HR Portal’ project. It includes employee personal records, compensation data, and performance reviews. It excludes the legacy archiving system which is not being migrated.”

Tips for Success:

Be specific about boundaries. If your project interacts with external systems, state clearly whether the data residing in those external systems is part of this assessment or if you are only assessing the data once it enters your project’s environment.

Section 2: Classification Framework Definitions

Instructions:

Before you can classify data, you must agree on what the labels mean. This section defines the standard four-tier classification model used by most enterprises. Review these definitions carefully to ensure the project team shares a common language.

2.1 Level 1: Public (Unclassified)

  • Definition: Information intended for free release to the public. Disclosure causes no harm to the organization.
  • Examples: Marketing materials posted on the website, press releases, job postings, published annual reports, product brochures.
  • Risk Profile: Low. The primary concern is integrity (preventing defacement), not confidentiality.

2.2 Level 2: Internal Use Only

  • Definition: Information intended for use within the organization. Unauthorized disclosure outside the company would be inappropriate but would likely cause only minor operational embarrassment or minor financial loss.
  • Examples: Internal memos, telephone directories, organizational charts, standard operating procedures, non-sensitive meeting minutes.
  • Risk Profile: Low to Medium. Access should be restricted to employees and approved contractors.

2.3 Level 3: Confidential

  • Definition: Sensitive information where unauthorized disclosure could cause significant financial loss, legal liability, or reputational damage. This data is usually restricted to specific teams or departments.
  • Examples: Pricing strategies, marketing plans before launch, detailed sales reports, partner contracts, non-public financial results, vendor pricing lists.
  • Risk Profile: High. Requires strict access controls (Need-to-Know basis).

2.4 Level 4: Restricted / Highly Confidential

  • Definition: Critical information requiring the highest level of protection. Unauthorized disclosure would cause severe, long-term damage to the organization, including regulatory fines, massive stock devaluation, or criminal liability.
  • Examples: Customer credit card numbers (PCI), Social Security Numbers/National IDs (PII), Patient Health Records (HIPAA), Merger & Acquisition targets, Top Secret trade secrets (e.g., the formula for the product).
  • Risk Profile: Critical. Requires encryption, multi-factor authentication, and continuous monitoring.

Section 3: Data Element Inventory and Mapping

Instructions:

This is the working core of the template. You must break down the project’s data into specific “elements” or “fields” and assign a classification level to each. Do not simply classify the “whole database” if possible; different fields often carry different risks.

Table 3.1: Data Inventory Mapping

Data Element / GroupDescriptionProposed ClassificationJustification
Example: User PasswordsHashed credentials for loginLevel 4: RestrictedCompromise allows total system takeover.
Example: Product CatalogList of items for sale and public pricesLevel 1: PublicInformation is available on the website.
[Data Element 1][Describe the data][Select Level 1-4][Why did you choose this level?]
[Data Element 2][Describe the data][Select Level 1-4][Why did you choose this level?]
[Data Element 3][Describe the data][Select Level 1-4][Why did you choose this level?]

Guidance for Completing Section 3:

  • Aggregation Risk: Be aware that combining two pieces of Level 2 data might create Level 3 data. For example, a list of employee names (Internal) combined with a list of home addresses (Confidential) creates a higher risk profile than either list alone.
  • Conservative Approach: If you are debating between two levels (e.g., Internal vs. Confidential), always choose the higher level. It is safer to over-protect than under-protect.

Tips for Success:

Involve the technical architect in this section. They can tell you exactly what fields are in the database schema. This prevents you from missing hidden fields like “metadata” or “transaction logs” which might contain sensitive info.

Section 4: Impact Assessment (The CIA Triad)

Instructions:

Classification is driven by impact. What happens if things go wrong? Analyze the data based on the “CIA Triad” of information security: Confidentiality, Integrity, and Availability. For each aspect, rate the potential impact of a failure as Low, Medium, or High.

4.1 Confidentiality Impact

  • Question: What is the damage if unauthorized people see this data?
  • Rating: [Low / Medium / High]
  • Scenario Analysis: Describe the worst-case scenario.
    • Example: “If the salary data is leaked, it would cause severe internal morale issues, resignations, and potential lawsuits for pay inequity. Therefore, Confidentiality Impact is High.”

4.2 Integrity Impact

  • Question: What is the damage if this data is corrupted, modified, or tampered with?
  • Rating: [Low / Medium / High]
  • Scenario Analysis: Describe the worst-case scenario.
    • Example: “If the financial reporting data is altered by a hacker, we could file incorrect tax returns, leading to SEC investigation and fines. Therefore, Integrity Impact is High.”

4.3 Availability Impact

  • Question: What is the damage if this data becomes inaccessible or lost (e.g., server crash)?
  • Rating: [Low / Medium / High]
  • Scenario Analysis: Describe the worst-case scenario.
    • Example: “If the historical sales archive is offline for 24 hours, it is inconvenient but business continues. Therefore, Availability Impact is Low.”

Summary of Classification:

Based on the highest rating in the CIA triad, confirm the overall classification level. Usually, the highest impact drives the classification. (e.g., If Confidentiality is High, the data is likely Level 3 or 4, even if Availability is Low).

Section 5: Handling Requirements

Instructions:

Now that you have classified the data, you must define the rules for how it is handled. This section translates the “Level” into actionable requirements for the IT and Business teams.

5.1 Labeling and Marking

Instructions:

How should the data be visually identified?

  • Electronic Documents: [e.g., “Must have a ‘CONFIDENTIAL’ watermark in the header.”]
  • Email: [e.g., “Subject line must start with [SECURE] for Restricted data.”]
  • Physical Media: [e.g., “USB drives must have a red sticker if containing Level 4 data.”]
  • User Interfaces: [e.g., “Screens displaying PII must mask characters (e.g., –-****-1234).”]

5.2 Storage Requirements

Instructions:

Where is it safe to put this data?

  • Level 1 (Public): Can be stored on public web servers, employee laptops, and shared drives.
  • Level 2 (Internal): Internal servers, password-protected SharePoint sites.
  • Level 3 (Confidential): Encrypted databases, access-controlled folders. Cannot be stored on personal devices or unencrypted USB drives.
  • Level 4 (Restricted): Strong encryption at rest (AES-256). Isolated network segments. strict “Need-to-Know” access lists. Cannot be stored on public cloud storage without specific security configurations (e.g., no public S3 buckets).

5.3 Transmission and Transport

Instructions:

How do we move the data safely?

  • Internal Network: [e.g., “Level 3+ data must use encrypted protocols (HTTPS/SMB3).”]
  • External Network (Internet): [e.g., “Level 3+ data must be sent via SFTP or encrypted email. Never send Level 4 data via standard email.”]
  • Physical Transport: [e.g., “Couriers transporting physical backup tapes must be bonded and tracked.”]

5.4 Destruction and Disposal

Instructions:

How do we get rid of it?

  • Paper: [e.g., “Level 3+ documents must be cross-cut shredded. Bin disposal is prohibited.”]
  • Digital Media: [e.g., “Hard drives must be degaussed or physically destroyed before recycling.”]
  • Cloud Data: [e.g., “Crypto-shredding (deleting the encryption keys) is required for Level 4 data.”]

Tips for Success:

Be very explicit about Email. This is the most common vector for data leaks. Explicitly state: “Do not email spreadsheets containing credit card numbers.”

Section 6: Access Control and Permissions

Instructions:

This section defines who gets access. It is not about listing specific names (which change too often) but about defining the logic of access.

6.1 Access Philosophy

  • Default Stance: [e.g., “Deny All. Access is only granted upon request.”]
  • Principle of Least Privilege: [Confirm that users will only receive the minimum access necessary to perform their job functions.]

6.2 Role-Based Access Control (RBAC) Definitions

Instructions:

Map the data classification to user roles.

Table 6.2: Role Matrix

Role NameDescriptionAccess LevelApproval Required By
AdministratorIT System AdminsRead/Write/Delete on All DataCIO / IT Director
ManagerTeam LeadsRead/Write on Department DataDepartment Head
UserGeneral StaffRead Only on Public/Internal DataManager
AuditorCompliance TeamRead Only (Logs)Legal/Compliance

6.3 Authentication Requirements

Instructions:

Align the login strength with the data value.

  • For Level 1 & 2 Data: Standard Username and Password.
  • For Level 3 Data: Strong Password policies (length/complexity) + MFA recommended.
  • For Level 4 Data: Multi-Factor Authentication (MFA) is Mandatory. Access from trusted devices only (e.g., corporate laptop).

Guidance:

If your project involves Level 4 data (like credit cards or health records) and you do not have MFA enabled, you are likely non-compliant with industry standards. This creates a significant project risk that must be flagged here.

Section 7: Regulatory and Compliance Overlays

Instructions:

Data classification is often driven by external laws. Identify which regulations apply to this specific data set. This helps justify the classification levels to stakeholders who might argue for lower security to save money.

  • [ ] GDPR (EU): Applies if data involves EU citizens. (Requires strict privacy controls).
  • [ ] CCPA/CPRA (California): Applies to California residents.
  • [ ] HIPAA (Healthcare): Applies to Protected Health Information (PHI).
  • [ ] PCI-DSS (Payments): Applies to credit/debit card data.
  • [ ] SOX (Financial): Applies to financial reporting data for public companies.
  • [ ] ITAR/EAR (Export Control): Applies to military or dual-use technology data.

Compliance Note:

If you checked “PCI-DSS,” the classification for that data must be Level 4 (Restricted). There is no flexibility here. The industry standards dictate the classification.

Section 8: Approval and Sign-Off

Instructions:

The classification is a business decision, not just an IT decision. The Business Data Owner must sign off to accept the classification. By signing, they acknowledge that they understand the risks and agree to the handling requirements defined in Section 5.

8.1 Data Owner Declaration

“I verify that I have reviewed the data inventory and classification levels. I agree that the designated levels accurately reflect the sensitivity of the business data and the potential impact of a breach. I authorize the implementation of the specified security controls.”

  • Name: _________________________________
  • Title: _________________________________
  • Signature: _____________________________
  • Date: __________________________________

8.2 Information Security Review

“I verify that the proposed controls (Section 5 & 6) are sufficient to protect the data at the classified levels according to organizational security policy.”

  • Name: _________________________________
  • Title: _________________________________
  • Signature: _____________________________
  • Date: __________________________________

Conclusion – Information Classification Assessment Template – Free Word Download

The Information Classification Assessment is the foundation of a risk-based security strategy. It prevents the project team from wasting resources on protecting trivial data while ensuring that the organization’s “crown jewels” are locked down tight.

Once this document is signed, it serves as a requirements document for the technical team. The developers know they need to build encryption fields; the network engineers know they need to segment traffic; and the legal team knows they need to draft specific clauses in vendor contracts.

As the project progresses, revisit this document if the scope changes. Adding a new feature that collects user birthdays or linking to a social media profile can change the classification from “Internal” to “Confidential” or “Restricted.” Keep this document alive, current, and accessible to the entire project leadership team. It is your guide to navigating the complex waters of data governance.

Appendix: Glossary of Terms

  • Availability: The assurance that systems and data are accessible by authorized users when needed.
  • Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
  • Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.
  • PII (Personally Identifiable Information): Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means.
  • Encryption: The process of converting information or data into a code, especially to prevent unauthorized access.
  • Data Owner: The individual with the authority to decide who has access to their data and the responsibility for its protection.

Meta Description:

A comprehensive Information Classification Assessment template to categorize project data by sensitivity (Public, Internal, Confidential, Restricted) and define handling requirements.

Discover More great insights at www.pmresourcehub.com