Safeguard 3.7 data classification scheme: evidence and audit

What a data classification scheme must show before an assessor will pass Safeguard 3.7

An audit or customer security questionnaire asks for your data classification scheme, and the answer is spread across a policy document, a sensitivity column in a spreadsheet, and sensitivity labels in a file share and a document wiki. Safeguard 3.7 asks for one enterprise-wide scheme, with labels such as Public, Confidential and Sensitive, that applies to all enterprise data and is reviewed at least once a year or after significant enterprise changes. The risk it addresses is simple: data that is sensitive gets handled like ordinary data because nobody can tell from its label what it is. The hard part is not writing the labels. It is turning the sensitivity levels defined in your data management process (Safeguard 3.1) into labels that are actually applied to real data, in the systems where that data lives.

Safeguard 3.7 is an IG2 Safeguard, so it does not apply to an IG1-only enterprise, but it is expected once you hold sensitive information at IG2 scale. The CIS Controls Assessment Specification scores it as failing in two cases: no classification scheme exists, or the scheme was last reviewed more than 12 months ago. Those two checks are the first thing to confirm. Find the document that defines the scheme, its version and the date of its last review, and the record of who approved that review. If the scheme lives only in an unversioned file, move it into a system that keeps a change history, so the review date and the changes between reviews can be shown to an assessor.

Once those basics pass, the assessor measures how completely the scheme covers sensitivity levels and how much data is correctly categorized. To answer that, you need a sample of data stores drawn from the data inventory (Safeguard 3.2), with the label each store carries and an owner who confirms the label is right. Gaps usually appear where labels were never applied, such as older file shares, exports and backups, or where labels conflict between tools. Ask the team for a short list of data stores that are out of scope or unlabeled, and decide for each whether to label it, retire it or justify it in the scheme. Confirm with your assessor which sample size and evidence format they expect before you start, because the CIS specification describes what to measure but not how to collect it.

Which data, systems, teams and providers a classification scheme must cover

Before labels can be written, an organization has to decide what the scheme reaches: which stores, which providers, which business units and who owns the result. Each of these choices changes how much work Safeguard 3.7 requires and how the assessment specification will score it, so they should be settled in writing before the labeling effort starts.

Data stores and file shares in scope

Start by listing every place data lives: databases, object storage, file servers, collaboration drives, email archives and endpoints. Safeguard 3.7 expects the scheme to apply across the enterprise, so a store left out of scope becomes a gap an assessor can find through the data inventory from Safeguard 3.2. Each additional store adds discovery, owner sign-off and label mapping work. Confirm the list against the inventory before estimating effort.

SaaS and service provider data

Data held by cloud applications and outsourced processors often sits outside the team's direct control, yet it still needs a classification. Decide whether provider-held data is classified by the enterprise, by the provider under contract, or both, and record that in the data flow documentation from Safeguard 3.8. Expect contract and configuration work to carry labels into these platforms, and confirm which providers support label export at all.

Business units with their own labels

Many enterprises already have departmental labels such as Internal Only or Client Confidential. Map each local label to the enterprise levels, for example Public, Confidential and Sensitive, instead of running parallel schemes. Assessors score how completely the scheme covers sensitivity levels, so an unmapped local label weakens the result. Document the mapping table and assign a single owner who approves changes.

Ownership of labels and reviews

Decide who approves the scheme, who applies labels to each data set, and who reviews them. Safeguard 3.7 requires review at least once a year or after significant enterprise changes, and the assessment specification fails the Safeguard when the last review is more than 12 months old. Name a data owner per domain, record the review date and tie it to the data management process from Safeguard 3.1.

Unlabeled and legacy data

Historical archives, backups and file shares created before the scheme exists rarely carry labels. Decide whether they are classified in bulk, classified on access, or handled under a default level until reviewed. Each choice trades labeling effort against exposure while the backlog is open. Ask for a count of unlabeled stores from the discovery process before approving a deadline.

How an assessor tests the data classification scheme

This table compares each test point the CIS assessment specification applies to Safeguard 3.7, the evidence an assessor typically asks for and the findings that most often appear. Read it as a preparation checklist: each row is a question the assessor will put to your scheme, and the final row explains why Safeguards 3.1 and 3.2 must be in place first. Any conclusion about the result comes from the assessor, not from DeployOpen.

Test point	Evidence the assessor requests	Common finding
Scheme exists	A written, enterprise-wide classification scheme with named sensitivity labels such as Public, Confidential and Sensitive, approved by an accountable owner	No written scheme exists, or labels are defined only inside individual teams or tools
Review within 12 months	Version history showing the last review date, the reviewer, the change log and any review triggered by significant enterprise change	Last review is older than 12 months, or the document has no review date at all
Coverage of sensitivity levels	Mapping of each label to a sensitivity level, handling rules and the systems or data types each level applies to	Labels exist, but some data types or business units have no level assigned
Correct categorization of data	A sample of data records or repositories with their assigned labels, compared against the data inventory and the labeling rules	Labels are missing or inconsistent on a meaningful share of sampled data, with no measurement of the gap
Dependency on Safeguard 3.1	The data management process defining sensitivity, ownership and handling, which the scheme should reference	Classification labels are not traceable to any documented sensitivity definition
Dependency on Safeguard 3.2	A data inventory that shows where sensitive data sits, so the assessor can compare labels with actual locations	No inventory exists, so the assessor cannot test whether categorization is complete or correct
Who makes the conclusion	The assessor reviews the evidence and issues the finding under the terms of its own engagement	Organizations often assume a partner's readiness review or an internal score equals the assessor's result

How to build a classification scheme that passes the 3.7 review

This sequence turns the sensitivity levels from your data management process into a labeled, approved and dated classification scheme that an assessor can trace from policy to individual data sets. Each step ends with a named artifact so you can show the review how the scheme was built.

Confirm sensitivity levels from the data management process
Start from the sensitivity definitions in your Safeguard 3.1 data management process, not from a blank page. The data owner, privacy lead and security lead confirm which sensitivity levels the process already defines and whether each level has a clear meaning for handling, retention and disposal. Where 3.1 is silent or vague, fix it there first so the labels have a documented source. The step closes with a short sensitivity register listing each level, its definition and the approver. Ask your assessor early which document they will treat as the authoritative source for levels.
Define labels and handling rules
Translate each sensitivity level into a label that people will recognize, such as Public, Confidential or Sensitive, and write a handling rule for each one. The rule should say who may access the data, how it is shared, where it may be stored and what must happen at disposal. Keep the number of labels small enough that staff can apply them correctly without guessing. The step closes with a labeling standard that names every label, its handling rule and the owner who can change it. Your labels do not have to match the examples in CIS wording, but they must be consistent across the scheme.
Map labels to the data inventory
Connect each label to the data sets recorded in your Safeguard 3.2 data inventory. Assign a data owner and a default label to each data set, and flag any data set that has no owner or no label. This is where classification becomes measurable, because the assessment looks at how completely the scheme covers sensitivity levels and how much data is correctly categorized. The step closes with an inventory extract showing every data set, its owner and its label, plus a short list of exceptions with a named person responsible for resolving each one.
Apply labels to systems and documents
Apply the labels where people and systems actually handle data. This includes file shares, document management and wiki spaces, databases and tagged storage locations, using the metadata or label features your platforms support. Confirm the capability in each tool before you promise it, because some platforms label at the document level and others only at the folder or container level. For self-hosted wiki and document platforms, version history and per-page permissions help show who changed a label and when. The step closes with a sample labeling report that a reviewer can test by picking items at random and checking the label against the inventory.
Record the approval
Have the scheme approved by an accountable executive or governance body, as your data management process requires. The approval record should show the version of the scheme, the date, the approver and the scope, including which business units and systems it covers. A scheme that exists only as a draft or only in an engineer's notes will not meet the requirement, even if labels are applied correctly. The step closes with a signed or recorded approval in your governance tool, stored with the scheme so that the assessor can see the approved version rather than a later working copy.
Set the annual review date and triggers
Set a recurring review date for the scheme once a year, and write down the events that force an earlier review, such as a significant enterprise change, a merger, a new regulated service or a new data type. The assessment treats a scheme last reviewed more than 12 months ago as a failure, so the review calendar is part of the control, not an administrative extra. The step closes with a review calendar entry, an owner for the review, and a log of prior review dates and changes. Confirm with your governance team which triggers they consider significant, because that definition is an internal decision that the assessor will test against your records.

Evidence that proves the scheme exists, is current and is applied

An assessor testing Safeguard 3.7 looks for three things: that a classification scheme exists, that it was reviewed recently, and that labels actually appear on data. The six artifacts below map to those checks, and each one goes stale in a different way, so each needs its own refresh routine between assessments.

Approved classification scheme document

This is the written scheme with its sensitivity labels, such as Public, Confidential and Sensitive, and a plain definition for each. Record the version number, the approver and the approval date on the document itself. Check that the scheme is enterprise-wide and that it links back to the data management process from Safeguard 3.1, since the labels should follow the sensitivity levels defined there. A wiki with version history can hold this document and show who changed what.

Review record within 12 months

The assessment specification fails Safeguard 3.7 when the scheme was last reviewed more than 12 months ago, so the review record is the artifact most likely to decide the result. Keep a dated log with the reviewer, the scope reviewed, the changes made and the sign-off. Set a recurring reminder for the next review before the current one closes, and confirm the record shows an actual review rather than a re-saved file.

Label-to-data mapping

This mapping states which data types, repositories and asset classes receive each label, and who decides when data sits between levels. Assessors use it to measure how completely the scheme covers sensitivity levels. Confirm that every label has at least one documented rule and that the mapping names the data owner responsible for applying it. Gaps usually appear where a new system was added without a rule.

Samples of labeled data across systems

Assessors measure how much data is correctly categorized, so they will sample records from several systems and check the label against the mapping. Pull samples from file shares, databases, collaboration tools and exported reports, and keep the query or export used to draw each sample. Include at least one system from each data inventory category. Samples taken from a single repository rarely show that the scheme is applied across the enterprise.

Change records after significant enterprise changes

Safeguard 3.7 requires review after significant enterprise changes, such as a merger, a new cloud platform, a new regulated product line or a major data migration. Keep a register that links each change to the review it triggered and the scheme updates that followed. Ask the change management team to flag data-relevant changes, because a review that is missing from the register is hard to defend even when the scheme is otherwise current.

Access rights to the scheme

The people who edit the scheme and approve label changes need defined permissions, so that an unreviewed edit cannot quietly replace an approved version. Export the role assignments for the wiki or document system that holds the scheme and compare them against the approver list. In BookStack-style systems, permissions can be set per role at the shelf, book, chapter or page level, which makes the edit rights easy to show to an assessor.

Open-source tools that keep classification evidence current

A classification scheme only passes Safeguard 3.7 if an assessor can see its current version, its last review and who approved changes, so the scheme itself needs a self-hosted home with a review trail. XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. That fits the scheme definition, the sensitivity levels and the labeling rules, because the review date and the prior versions can be shown side by side. Confirm with your own environment whether the version history retains the review sign-off you need, or whether a separate approval record is still required.

BookStack, licensed under MIT, handles who may edit the scheme and the handling guidance attached to each label. User abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. In practice, a data owner or the security team might hold edit rights on the scheme pages while business units can only read them, which keeps the scheme under control of the people accountable for it. Test the role model with a reviewer account before you rely on it for the annual review, since the permission layers interact and a broad override can quietly widen access.

CISO Assistant, licensed under AGPL-3.0-only, is the tool for tracking control evidence and mapping framework requirements. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs assessments with automatic mapping between them, so a classification review can be linked to the requirements it supports in each framework. Its use cases are evidence and assessment records, not the labels themselves: it will not tag files in your data estate. Before relying on it, confirm which labeling or discovery features your data sources actually support, and check the AGPL-3.0-only terms with your legal team if you plan to modify the software or offer it to others.

What a data classification scheme costs in money and effort

This table breaks down the cost components of establishing and maintaining a Safeguard 3.7 classification scheme, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No dollar amounts or durations are given because none are supplied for this Safeguard, so use the drivers column to scope a quote and ask providers to price each row separately.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor or open-source project, plus internal or partner staff to deploy and run it	Open-source tools remove license spend, but hosting, storage and administration remain recurring	Number of data stores to connect, whether labels must be enforced in systems or only recorded in a register
Data owner time to agree levels	Data owners, business leads and the team that writes the scheme	One-time to agree the initial levels, then recurring at each annual review	Number of sensitivity levels, how many data domains exist, and whether the data management process from Safeguard 3.1 already defines sensitivity
Engineering time to apply labels	Internal engineers or a partner preparing label fields, metadata and tagging rules in each system	One-time for the initial pass, recurring for new data stores and changed data	State of the data inventory from Safeguard 3.2, number of data stores, and whether labels can be applied automatically
Evidence upkeep for the annual review	Compliance or security staff who record the review date, approvals and change history	Recurring every year, and after significant enterprise changes	Whether the scheme is kept in version-controlled documentation, and how many approvals the review needs
Classification accuracy checks	Security or data governance staff who sample labeled data	Recurring, with a larger effort after major system changes	Volume of unlabeled or mislabeled data found in the inventory, and the coverage target the organization sets
External review or assessment	Independent auditor, assessor or consultant, paid by the organization	Recurring when a framework or customer requires it	Assessment scope, the frameworks mapped to Safeguard 3.7, and how well evidence is already organized
Auditor sampling	Independent auditor, who selects labeled records and reviews them	Recurring per audit cycle	Sample size set by the auditor, number of data stores in scope, and quality of the inventory the sample is drawn from

Who owns the scheme, who can outsource it and what the auditor checks

Your organization owns the classification scheme and every decision that gives it meaning. Safeguard 3.7 asks for an enterprise-wide scheme with sensitivity labels such as Public, Confidential and Sensitive, reviewed at least once a year or after significant enterprise changes. Those labels only work if the people accountable for the data agree on what each one means and who may approve exceptions. That accountability cannot be delegated to a vendor.

Policy ownership: a named executive or governance body approves the classification policy and its label definitions.
Label approvals: data owners decide which label applies to each data set and sign off on any downgrade or exception.
Handling rules: owners define the handling requirements tied to each label, linked to the data management process in Safeguard 3.1.
Annual review: the owner schedules the review, records what changed and re-approves the scheme, including after mergers, new products or new regulators.
Staff communication: employees need to know the labels and how to apply them, which feeds the training work in Control 14.

Confirm that each label has a named owner and a dated approval record before any outside party starts work.

Where classification programs fail the 12-month review test

Safeguard 3.7 is measured on whether a scheme exists, covers the sensitivity levels in use and was reviewed within the last 12 months. Most programs fail not because the labels are wrong but because the scheme never reaches the systems that hold data, has no owner and is not revisited when the enterprise changes.

Labels that stay in policy

The scheme is written into a policy document, but no system displays, applies or enforces the labels. Assessors look for evidence that classified data carries its label where people and systems work, such as document headers, repository tags or database metadata. To check this, pick ten data sets at random and ask whether each one shows a label that matches the scheme. If the answer is no for most of them, the scheme exists on paper only.

Scheme approved once, never reviewed

A classification scheme signed off at launch and left untouched fails the review test once 12 months pass. The CIS assessment specification scores Safeguard 3.7 as failing when the last review is more than 12 months old. Put the review date, the approver and the change log in the policy record, and schedule the review as a recurring task with a named reviewer.

Levels that do not match the data management process

Labels such as Public, Confidential and Sensitive must correspond to the sensitivity levels defined in the data management process under Safeguard 3.1. When the two documents use different levels, handling rules, retention periods and disposal methods cannot be tied to a label. Map every classification level to a handling rule in the data management process, and confirm that no level exists in one document only.

No owner for label decisions

When nobody is accountable for labeling decisions, staff guess, and the same data set receives different labels in different teams. Name a data owner for each data domain who decides the label, and a central contact who resolves disputes. Record these assignments in the data management process so an assessor can trace who decided what and when.

Labels applied to documents only

Many programs classify files and email but never reach databases, data lakes, SaaS platforms or backups, where most sensitive data sits. The data inventory from Safeguard 3.2 should record a classification for each data store, not just each file type. Ask for the classification field in every database schema and storage bucket that holds regulated data, and treat any store without one as an open gap.

No record after major enterprise change

Mergers, new cloud regions, a new core banking platform or a change in the regulatory perimeter can make existing labels wrong. The assessment specification expects a review after significant enterprise changes as well as the annual review. Keep a short trigger list in the policy, such as a new business line, a new service provider holding data or a new jurisdiction, and record a dated review each time one of those events occurs.

Questions buyers ask about the cost, effort and timing of Safeguard 3.7

Does an IG1 organization have to establish a data classification scheme?

No. Safeguard 3.7 is assigned to Implementation Groups 2 and 3, not IG1, so an organization that only targets IG1 is not measured against it. IG1 is the essential cyber hygiene baseline and covers 56 Safeguards. An IG2 or IG3 organization, or one that has moved up to those groups because it holds sensitive information, should plan for this Safeguard. Confirm your Implementation Group with your own risk profile and any contract or regulator that names the CIS Controls before you decide the work is out of scope.

How much effort does a data classification scheme take to build?

The effort depends mostly on how much data the enterprise holds, how many systems it lives in, and whether a data management process already defines sensitivity levels. Safeguard 3.7 builds on Safeguards 3.1 and 3.2, which the assessment specification lists as prerequisites because they produce the data the measurement needs. If the data management process and data inventory are missing, expect the classification work to start there. Ask any partner to split the effort into defining labels, mapping data owners, applying labels to systems and writing the review procedure, so each part can be priced and checked.

What does the work need from internal staff?

The scheme needs business input more than technical skill. Data owners must agree on what Public, Confidential and Sensitive mean in practice, and they must confirm which datasets fall into each level. Security or compliance staff define the scheme and keep it consistent. Platform or application teams apply the labels in the systems they run. Ask your partner which decisions require named owners from each business unit, because delays in those decisions usually extend the timeline more than technical work does.

Can we run the classification scheme ourselves, or do we need a partner?

An organization can run the scheme in-house if it has staff who understand its data and the authority to set labels across business units. A partner is useful when those skills or that authority are missing, or when the labels must be applied to self-hosted platforms that the internal team has not yet documented. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own environment, and it prepares the systems and evidence for assessment. The organization still owns the scheme, and only an independent assessor or certification body issues reports or certificates.

How often must the classification scheme be reviewed?

Safeguard 3.7 requires review once a year, and also after significant enterprise changes such as a merger, a new regulated product or a major platform migration. The assessment specification scores the Safeguard as failing when no scheme exists or when the last review was more than 12 months ago. Put the review date in a calendar owned by a named person, and record what changed at each review so the assessor can see the scheme is maintained rather than written once.

What will an assessor check first for Safeguard 3.7?

An assessor usually starts by asking whether a classification scheme exists and when it was last reviewed, because the assessment specification fails the Safeguard on those two points alone. Next, they check how completely the scheme covers sensitivity levels and whether a sample of data is labeled correctly. Prepare a dated scheme document, the review record, and a sample showing labels applied in real systems. Confirm with your assessor which samples and formats they expect before the fieldwork starts.

What ongoing costs should we plan for after the scheme is in place?

The recurring costs are the annual review, label maintenance as new data sources appear, and staff time for classifying new datasets. Costs go up when the enterprise adds systems quickly, runs many service providers that handle data, or has no automated labeling. One-time costs include defining the scheme and the first labeling pass. When you request a quote, ask for the one-time and recurring components separately, and ask who maintains the labels after the engagement ends.

How DeployOpen works on this

DeployOpen helps regulated organizations prepare the systems, documented scheme and evidence that Safeguard 3.7 asks for, inside the client's own infrastructure. The organization owns its classification scheme and decisions, and an independent assessor or auditor performs any formal assessment.

How we scope

Written scope lists which data sources, repositories and platforms the classification scheme must cover before work starts.
Scope names the sensitivity labels in use, such as Public, Confidential and Sensitive, and who approves them.
Scope states the annual review cycle and the trigger events that require a review after significant enterprise changes.

How we build

We configure the chosen open-source platforms so classification labels can be recorded and applied to data objects consistently.
We link the labels to the data management process and data inventory outputs from Safeguards 3.1 and 3.2.
We test label application on sample data sets and document where labels are missing or inconsistent.

How we hand over

Deliverables include the written classification scheme, label definitions, owner assignments and the review record.
Documentation records the version history of the scheme, showing who changed each label and when.
We walk the client's team through the evidence pack so they can answer assessor questions about review dates and coverage.

How we support

Ongoing support is available as a retainer for annual reviews, label updates and platform upgrades.
Retainers can cover periodic checks that the review date stays within the twelve-month window the assessment specification uses.
The client confirms with its assessor which evidence formats and review records are accepted before the final pack is assembled.