Knowing What Data Is Where

Data classification per application determines the review depth, the residency requirement, the access controls and the incident priority. It is one field and it does more work than the rest combined.

A workable classification

Four levels are enough for most organisations.

Public. Material intended for publication.

Internal. Ordinary business information. Disclosure would be unwelcome and not serious.

Confidential. Commercially sensitive, or personal data at ordinary scale. Disclosure would cause real harm.

Regulated. Data subject to specific legal requirements — health, financial, government, or personal data at large scale or of a special category.

More levels than that and nobody applies them consistently.

Classifying an application

Ask the owner what goes in it, which is the fastest method and depends on them knowing.

Check what actually goes in it, which frequently differs. A tool intended for project notes accumulates customer names, contract terms and occasionally credentials.

Classify by the highest sensitivity present, not the intended use.

Re-ask annually, because usage drifts upward. Applications acquire more sensitive data over time and almost never less.

The drift problem

The reason a one-time classification is inadequate.

A team starts using a tool for something harmless and gradually puts more in it.

An integration is added that pulls customer records into a system classified as internal.

A new feature — file attachments, comments, exports — changes what the tool can hold.

Detect it by asking at review, and by watching integration changes. A new connection between a regulated system and an internal-classified one is a reclassification trigger.

What the classification drives

Review depth at procurement and at re-review.

Residency requirements.

Whether SSO and multi-factor authentication are mandatory rather than preferred.

Access review frequency.

Retention and deletion requirements.

Incident priority.

Whether the application may be used at all on unmanaged devices.

Publish the matrix: classification down the side, requirements across the top. It makes the requirement predictable rather than a negotiation each time.

Where sensitive data ends up unexpectedly

Worth checking specifically.

Support and ticketing systems, which accumulate whatever customers send, including documents and credentials.

Chat platforms, where people paste things.

Note-taking and wiki tools.

Analytics platforms processing identifiable user data.

Backup and export destinations, which inherit the sensitivity of their source and are frequently classified lower.

Test and development environments populated with copies of production data, which is the classic failure.

Each of these deserves a deliberate look rather than a classification inherited from the original purpose.

Minimisation

The control that reduces the problem rather than managing it.

Ask whether the data needs to be there. Frequently a workflow can achieve the same result without the sensitive field.

Redact at the boundary where possible — support systems that strip payment data, integrations that pass identifiers rather than records.

Set retention within the application, so it holds less over time rather than more.

A tool holding less sensitive data is cheaper to review, cheaper to secure and less serious when something goes wrong. Minimisation is the only intervention that improves all three at once.

The classification matrix

Publishing what each classification requires makes the requirement predictable rather than a negotiation on each application.

Down the side: public, internal, confidential, regulated.

Across the top: review depth, SSO required, multi-factor required, access review frequency, residency constraint, retention rule, permitted on unmanaged devices, incident priority.

Fill in every cell, including the ones where the answer is "no requirement".

One page, published, and referenced from the request path.

The value is that a requester can predict the answer before asking, and an owner can see what changing a classification would mean. Both reduce the number of conversations that turn into negotiations.

Where copies accumulate

Classification is applied to applications and data does not stay in one.

Exports and reports downloaded to laptops and shared drives.

Backups, which inherit sensitivity and are frequently classified lower.

Test environments populated from production, which is the classic failure.

Integrations pushing records into lower-classified systems.

Support tickets containing attachments customers sent.

Analytics platforms holding identifiable records.

Trace the copies for your highest-classified data specifically, which is a half-day exercise per system and frequently finds a copy in a place with far weaker controls than the original.