Data Classification Policy Architect

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:

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?

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

1. 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.
2. 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.
3. Enable the compliance overlays that apply and check where each regulated data type lands.
4. Fill in the policy metadata — title, organisation, version, effective date and review schedule (annual, semi-annual or quarterly).
5. Read the live preview, which shows the assembled document: purpose and scope, classification levels, handling rules, compliance mapping, roles and responsibilities, and review schedule.
6. 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.