Data Classification Policy Architect
Design comprehensive data classification policies with government (TS/S/C/U) or commercial (Restricted/Confidential/Internal/Public) schemas. Define handling rules for storage, transmission, disposal, and access with compliance overlays for HIPAA, PCI-DSS, GDPR, and CMMC.
Data Classification Policy Architect — Build a Real Policy, Not a Template
Most data classification policies fail for the same reason: they name the levels and stop. “Confidential” means nothing until someone can answer whether it may be emailed, where it may be stored, who approves access, how long it is kept and how it is destroyed. This tool builds the whole thing — a classification schema, a complete set of handling rules for every level across five control areas, compliance overlays that map regulated data types onto your levels, roles and responsibilities, and a review schedule — then exports it as a formatted PDF policy document.
It runs entirely in your browser, saves your progress locally, and requires no account. It is aimed at security leads, compliance managers and CISSP-track practitioners who need a defensible Domain 2 asset security artefact rather than a two-page template that an auditor will hand straight back.
Choose a Schema
The tool offers three starting points:
| Schema | Levels | Fits |
|---|---|---|
| Commercial | Restricted, Confidential, Internal, Public | Almost every private-sector organisation |
| Government / military | Top Secret, Secret, Confidential, Unclassified | National security contexts, where levels are defined by the damage disclosure would cause |
| Custom | Two to six levels you define | Organisations with an existing vocabulary they cannot change |
The government schema is worth understanding even if you never use it, because it is where the logic of classification is clearest: levels are defined by the expected consequence of unauthorised disclosure — exceptionally grave damage, serious damage, damage — rather than by who owns the file. Commercial schemes work best when written the same way, in terms of business impact rather than departmental ownership.
A practical warning on level count: four is the sweet spot. Two is too coarse to drive different handling. Six or more produces levels nobody can distinguish under pressure, and the failure mode of an over-granular scheme is that everything gets marked at the highest level, which is functionally the same as having no scheme at all.
Handling Rules: The Part Most Policies Skip
For every level, the tool pre-populates and lets you edit fifteen specific rules across five areas. This is the section that turns a label into an enforceable control.
- Storage — encryption requirement at rest, approved storage locations, backup requirements. Higher levels move from “encryption recommended” to AES-256 required, from any storage to approved enterprise or secured facilities, and from a standard backup schedule to daily encrypted offsite backups.
- Transmission — encryption in transit (TLS version floor), approved channels, and DLP posture. At the top level this typically means a secure portal only, no email and no removable media, with DLP set to block rather than alert.
- Access control — who may access, what approval is required, and what logging and review applies. This is where least privilege becomes concrete: named approval by the data owner, full access logging, quarterly audit review.
- Disposal and retention — the retention minimum, the destruction method, and whether a certificate of destruction is required. Crypto-erase plus physical destruction at the top, secure deletion in the middle, standard deletion for public data.
- Labelling — marking requirements, header and footer text, and watermarking. Unlabelled data cannot be handled correctly by anyone who did not create it, which is why labelling is a control rather than cosmetics.
Every field is editable. The defaults are deliberately opinionated so that you are correcting a real policy rather than filling in a blank one.
Compliance Overlays
The overlay step maps regulated data types onto your levels so the policy answers the question an auditor will ask: where does this regulated category sit in your scheme?
| Framework | Data types mapped | What drives the minimum level |
|---|---|---|
| HIPAA | Protected Health Information, electronic PHI | Security Rule safeguards at 45 CFR 164.308–312, including access control, audit controls and transmission security |
| PCI-DSS | Cardholder data, sensitive authentication data | Sensitive authentication data must not be retained after authorisation; PAN must be rendered unreadable wherever stored |
| GDPR | Personal data, special category data, biometric and genetic data | Article 9 special categories require an additional lawful condition and, in practice, stronger handling than ordinary personal data |
| CMMC | Controlled Unclassified Information, Federal Contract Information | CUI protection requirements derive from NIST SP 800-171; FCI from the basic safeguarding requirements in FAR 52.204-21 |
| SOX | Financial reporting data, internal controls documentation | Integrity and change control over the records supporting financial statements |
Enable the frameworks that apply and the mapping table appears in both the preview and the exported policy. The mappings are defaults reflecting common practice, not regulatory instructions — adjust the minimum level where your own risk assessment says otherwise, and record why.
How to Use the Tool
- Pick a schema and, if custom, define your levels with a name, a description written in terms of business impact, a colour and a rank.
- Work through the handling rules level by level. Change the defaults to match what your environment can actually enforce today — a rule you cannot enforce is a finding waiting to be written.
- Enable the compliance overlays that apply and check where each regulated data type lands.
- Fill in the policy metadata — title, organisation, version, effective date and review schedule (annual, semi-annual or quarterly).
- Read the live preview, which shows the assembled document: purpose and scope, classification levels, handling rules, compliance mapping, roles and responsibilities, and review schedule.
- Export the PDF, then take it through your approval process. Progress is saved in your browser, so you can come back to it.
Roles That Make Classification Work
The policy assigns four roles, and getting these named — with actual people behind them — is what separates a policy that operates from one that exists.
- Data owner — assigns the classification level, approves access, and reviews the classification periodically. Almost always a business role, not IT. The single most common cause of a failed classification programme is IT being made owner of data it does not understand.
- Data custodian — implements the technical controls, manages storage and backups, enforces handling rules, reports incidents. Usually IT or platform engineering.
- Data user — follows the handling rules, reports misclassification, completes training, protects data in their custody.
- Information security — defines the standard, audits against it, provides training, and runs the DLP and monitoring tooling.
Two further points that policies routinely omit and auditors routinely ask about. First, reclassification: data changes value over time, and a scheme with no downgrade path accumulates restricted data forever. Say who may downgrade and on what basis. Second, aggregation: individually innocuous records can become sensitive in bulk — a single delivery address is Internal, the full customer address file is not. State that aggregation may raise the classification level, or your scheme will be wrong at exactly the moment it matters.
Frequently Asked Questions
How many classification levels should we have?
Four. Enough to drive genuinely different handling, few enough that staff can apply them without a decision tree. If you find yourself needing a fifth, check first whether the real problem is a missing handling rule rather than a missing level.
Does the exported policy make us compliant?
No. It is an informational aid producing a draft document, not legal advice, and a policy is only one element of a control. Frameworks test whether the policy is approved, communicated, and operating — meaning labelled data, enforced access, evidence of reviews. Have counsel or your compliance lead review before adoption.
Where does data classification appear in the frameworks?
Widely. ISO 27001 addresses information classification and labelling in its Annex A controls; SOC 2 relies on it under the confidentiality criteria and throughout logical access; HIPAA’s minimum necessary principle is unworkable without it; PCI-DSS depends on knowing exactly where cardholder data lives; and CMMC requires CUI to be identified and marked before it can be protected. It is also CISSP Domain 2 — asset security — in its entirety.
Should we classify everything?
No, and trying is how programmes die. Set a default level for unlabelled data (Internal is the usual choice), then classify explicitly where it changes handling: regulated data, financial records, source code, customer content, HR files. The default catches the long tail.
What is the difference between classification and categorisation?
In federal usage, security categorisation under FIPS 199 rates a system by the potential impact on confidentiality, integrity and availability — low, moderate or high — and drives the control baseline. Data classification labels the information itself by sensitivity. They interact, but a policy that conflates them will confuse anyone working to a NIST baseline.
How do we handle data we receive from customers?
Map their scheme to yours in the contract, and state the mapping in the policy. The frequent failure is receiving data labelled “Confidential” under a customer scheme that means something stricter than your “Confidential”, and handling it to your definition.
Does the tool store our policy anywhere?
No. Everything stays in your browser — progress is saved to local storage on your device and the PDF is generated locally. Nothing is sent to us.
What should we build alongside this?
The classification policy sets the rules; other documents operationalise them. The security policy generator produces the acceptable use, access control and incident response policies that reference your levels. For the disposal rules, the media sanitization advisor gives the sanitisation method appropriate to each media type. To find where sensitive data already sits in documents you are about to share, use the PII redactor, and if GDPR retention drives your disposal periods, set them with the GDPR role and retention mapper.
Data Classification Policy Architect — Build a Real Policy, Not a Template
Most data classification policies fail for the same reason: they name the levels and stop. “Confidential” means nothing until someone can answer whether it may be emailed, where it may be stored, who approves access, how long it is kept and how it is destroyed. This tool builds the whole thing — a classification schema, a complete set of handling rules for every level across five control areas, compliance overlays that map regulated data types onto your levels, roles and responsibilities, and a review schedule — then exports it as a formatted PDF policy document.
It runs entirely in your browser, saves your progress locally, and requires no account. It is aimed at security leads, compliance managers and CISSP-track practitioners who need a defensible Domain 2 asset security artefact rather than a two-page template that an auditor will hand straight back.
Choose a Schema
The tool offers three starting points:
| Schema | Levels | Fits |
|---|---|---|
| Commercial | Restricted, Confidential, Internal, Public | Almost every private-sector organisation |
| Government / military | Top Secret, Secret, Confidential, Unclassified | National security contexts, where levels are defined by the damage disclosure would cause |
| Custom | Two to six levels you define | Organisations with an existing vocabulary they cannot change |
The government schema is worth understanding even if you never use it, because it is where the logic of classification is clearest: levels are defined by the expected consequence of unauthorised disclosure — exceptionally grave damage, serious damage, damage — rather than by who owns the file. Commercial schemes work best when written the same way, in terms of business impact rather than departmental ownership.
A practical warning on level count: four is the sweet spot. Two is too coarse to drive different handling. Six or more produces levels nobody can distinguish under pressure, and the failure mode of an over-granular scheme is that everything gets marked at the highest level, which is functionally the same as having no scheme at all.
Handling Rules: The Part Most Policies Skip
For every level, the tool pre-populates and lets you edit fifteen specific rules across five areas. This is the section that turns a label into an enforceable control.
- Storage — encryption requirement at rest, approved storage locations, backup requirements. Higher levels move from “encryption recommended” to AES-256 required, from any storage to approved enterprise or secured facilities, and from a standard backup schedule to daily encrypted offsite backups.
- Transmission — encryption in transit (TLS version floor), approved channels, and DLP posture. At the top level this typically means a secure portal only, no email and no removable media, with DLP set to block rather than alert.
- Access control — who may access, what approval is required, and what logging and review applies. This is where least privilege becomes concrete: named approval by the data owner, full access logging, quarterly audit review.
- Disposal and retention — the retention minimum, the destruction method, and whether a certificate of destruction is required. Crypto-erase plus physical destruction at the top, secure deletion in the middle, standard deletion for public data.
- Labelling — marking requirements, header and footer text, and watermarking. Unlabelled data cannot be handled correctly by anyone who did not create it, which is why labelling is a control rather than cosmetics.
Every field is editable. The defaults are deliberately opinionated so that you are correcting a real policy rather than filling in a blank one.
Compliance Overlays
The overlay step maps regulated data types onto your levels so the policy answers the question an auditor will ask: where does this regulated category sit in your scheme?
| Framework | Data types mapped | What drives the minimum level |
|---|---|---|
| HIPAA | Protected Health Information, electronic PHI | Security Rule safeguards at 45 CFR 164.308–312, including access control, audit controls and transmission security |
| PCI-DSS | Cardholder data, sensitive authentication data | Sensitive authentication data must not be retained after authorisation; PAN must be rendered unreadable wherever stored |
| GDPR | Personal data, special category data, biometric and genetic data | Article 9 special categories require an additional lawful condition and, in practice, stronger handling than ordinary personal data |
| CMMC | Controlled Unclassified Information, Federal Contract Information | CUI protection requirements derive from NIST SP 800-171; FCI from the basic safeguarding requirements in FAR 52.204-21 |
| SOX | Financial reporting data, internal controls documentation | Integrity and change control over the records supporting financial statements |
Enable the frameworks that apply and the mapping table appears in both the preview and the exported policy. The mappings are defaults reflecting common practice, not regulatory instructions — adjust the minimum level where your own risk assessment says otherwise, and record why.
How to Use the Tool
- Pick a schema and, if custom, define your levels with a name, a description written in terms of business impact, a colour and a rank.
- Work through the handling rules level by level. Change the defaults to match what your environment can actually enforce today — a rule you cannot enforce is a finding waiting to be written.
- Enable the compliance overlays that apply and check where each regulated data type lands.
- Fill in the policy metadata — title, organisation, version, effective date and review schedule (annual, semi-annual or quarterly).
- Read the live preview, which shows the assembled document: purpose and scope, classification levels, handling rules, compliance mapping, roles and responsibilities, and review schedule.
- Export the PDF, then take it through your approval process. Progress is saved in your browser, so you can come back to it.
Roles That Make Classification Work
The policy assigns four roles, and getting these named — with actual people behind them — is what separates a policy that operates from one that exists.
- Data owner — assigns the classification level, approves access, and reviews the classification periodically. Almost always a business role, not IT. The single most common cause of a failed classification programme is IT being made owner of data it does not understand.
- Data custodian — implements the technical controls, manages storage and backups, enforces handling rules, reports incidents. Usually IT or platform engineering.
- Data user — follows the handling rules, reports misclassification, completes training, protects data in their custody.
- Information security — defines the standard, audits against it, provides training, and runs the DLP and monitoring tooling.
Two further points that policies routinely omit and auditors routinely ask about. First, reclassification: data changes value over time, and a scheme with no downgrade path accumulates restricted data forever. Say who may downgrade and on what basis. Second, aggregation: individually innocuous records can become sensitive in bulk — a single delivery address is Internal, the full customer address file is not. State that aggregation may raise the classification level, or your scheme will be wrong at exactly the moment it matters.
Frequently Asked Questions
How many classification levels should we have?
Four. Enough to drive genuinely different handling, few enough that staff can apply them without a decision tree. If you find yourself needing a fifth, check first whether the real problem is a missing handling rule rather than a missing level.
Does the exported policy make us compliant?
No. It is an informational aid producing a draft document, not legal advice, and a policy is only one element of a control. Frameworks test whether the policy is approved, communicated, and operating — meaning labelled data, enforced access, evidence of reviews. Have counsel or your compliance lead review before adoption.
Where does data classification appear in the frameworks?
Widely. ISO 27001 addresses information classification and labelling in its Annex A controls; SOC 2 relies on it under the confidentiality criteria and throughout logical access; HIPAA’s minimum necessary principle is unworkable without it; PCI-DSS depends on knowing exactly where cardholder data lives; and CMMC requires CUI to be identified and marked before it can be protected. It is also CISSP Domain 2 — asset security — in its entirety.
Should we classify everything?
No, and trying is how programmes die. Set a default level for unlabelled data (Internal is the usual choice), then classify explicitly where it changes handling: regulated data, financial records, source code, customer content, HR files. The default catches the long tail.
What is the difference between classification and categorisation?
In federal usage, security categorisation under FIPS 199 rates a system by the potential impact on confidentiality, integrity and availability — low, moderate or high — and drives the control baseline. Data classification labels the information itself by sensitivity. They interact, but a policy that conflates them will confuse anyone working to a NIST baseline.
How do we handle data we receive from customers?
Map their scheme to yours in the contract, and state the mapping in the policy. The frequent failure is receiving data labelled “Confidential” under a customer scheme that means something stricter than your “Confidential”, and handling it to your definition.
Does the tool store our policy anywhere?
No. Everything stays in your browser — progress is saved to local storage on your device and the PDF is generated locally. Nothing is sent to us.
What should we build alongside this?
The classification policy sets the rules; other documents operationalise them. The security policy generator produces the acceptable use, access control and incident response policies that reference your levels. For the disposal rules, the media sanitization advisor gives the sanitisation method appropriate to each media type. To find where sensitive data already sits in documents you are about to share, use the PII redactor, and if GDPR retention drives your disposal periods, set them with the GDPR role and retention mapper.
Data Classification Confusion?
Our team implements data classification schemes, handling procedures, and DLP controls.
What Is Data Classification
Data classification is the process of organizing data into categories based on its sensitivity, value, and regulatory requirements. A classification framework assigns labels (such as Public, Internal, Confidential, Restricted) that determine how data must be handled, stored, transmitted, and disposed of throughout its lifecycle.
Data classification is the foundation of any data protection program. Without knowing what data you have and how sensitive it is, you cannot apply appropriate security controls, meet compliance obligations, or respond effectively to data breaches. Regulations including GDPR, HIPAA, PCI DSS, and CMMC all require organizations to classify and protect data according to its sensitivity.
Classification Levels
| Level | Description | Examples | Handling Requirements |
|---|---|---|---|
| Public | No harm if disclosed | Marketing materials, public website content | No restrictions |
| Internal | Low harm if disclosed externally | Internal policies, org charts, meeting notes | Access restricted to employees |
| Confidential | Significant harm if disclosed | Customer data, financial reports, source code | Encryption, access controls, NDA required |
| Restricted | Severe harm if disclosed | PII, PHI, payment card data, trade secrets | Strongest controls, encryption at rest and in transit, strict access |
Regulatory Classification Requirements
| Regulation | Data Types | Required Classification |
|---|---|---|
| GDPR | Personal data of EU residents | Must identify and protect all personal data processing |
| HIPAA | Protected Health Information (PHI) | Must classify and safeguard all PHI |
| PCI DSS | Cardholder data | Must identify all locations where cardholder data is stored, processed, or transmitted |
| CMMC | Controlled Unclassified Information (CUI) | Must classify and protect CUI per NIST 800-171 |
| SOX | Financial records | Must classify and protect financial reporting data |
Common Use Cases
- Data protection program design: Establish a classification framework that drives security controls, access policies, and data handling procedures across the organization
- Compliance readiness: Map data classifications to regulatory requirements to demonstrate that appropriate controls are in place for each data category
- Cloud migration planning: Classify data before migration to determine which workloads can move to public cloud, which require private cloud, and which must remain on-premises
- Incident response prioritization: During a breach, data classification determines the severity, notification requirements, and response urgency based on what data was exposed
- Vendor risk management: Classify data shared with third parties to determine the level of due diligence, contractual protections, and monitoring required
Best Practices
- Start with a simple scheme — Three to four classification levels are sufficient for most organizations. Overly complex schemes lead to inconsistent application and user fatigue.
- Classify at creation — Data should be classified when it is created or received, not after the fact. Build classification into business processes and data entry workflows.
- Train all employees — Every person who handles data must understand the classification levels and their handling requirements. Annual training with practical examples is essential.
- Automate where possible — Use data loss prevention (DLP) tools to scan for sensitive data patterns (SSNs, credit card numbers, PHI) and automatically apply or suggest classifications.
- Review and reclassify periodically — Data sensitivity changes over time. Financial results are confidential before earnings release but public afterward. Establish review cycles for reclassification.
Frequently Asked Questions
Common questions about the Data Classification Policy Architect
The U.S. government uses four classification levels: Top Secret (exceptionally grave damage to national security), Secret (serious damage), Confidential (damage to national security), and Unclassified (no damage). Each level has specific handling, storage, transmission, and destruction requirements defined by Executive Order 13526.
Common commercial classification schemas include: Restricted (highest sensitivity - trade secrets, PII), Confidential (internal sensitive data - financial records, HR data), Internal (business use only - policies, procedures), and Public (freely shareable - marketing materials, press releases). Some organizations add a fifth "Critical" level.
Higher classification levels require stricter controls: encryption at rest and in transit (Restricted), access controls and audit logging (Confidential), basic access controls (Internal), and no special controls (Public). This tool lets you define specific handling rules for storage, transmission, disposal, and access at each level.
Data classification is foundational to compliance. HIPAA requires identifying PHI, PCI-DSS requires identifying cardholder data, GDPR requires identifying personal data, and CMMC requires identifying CUI. This tool provides compliance overlays that map classification levels to regulatory requirements for each framework.
The data owner (typically a business unit leader or executive) is responsible for classifying data based on its sensitivity and value. The data custodian (typically IT) implements the technical controls required by the classification. Data users must handle information according to its classification level.
Explore More Tools
Continue with these related tools
ℹ️ Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.