Safeguard 3.12 Segment data by sensitivity: requirements and evidence

What Safeguard 3.12 requires when sensitive data shares infrastructure

If you run an IG2 or IG3 enterprise where sensitive and lower-sensitivity workloads share servers, databases, storage or pipelines, Safeguard 3.12 asks you to separate where data is processed and stored by its sensitivity level, so that assets meant for less sensitive data are never used to handle sensitive data. The Safeguard sits in the Data asset class and the Protect security function, and it applies to Implementation Groups 2 and 3 only, so IG1 organizations do not carry it as a requirement. The point is not to build a perfect enclave for every record. It is to make sure the boundary between sensitivity levels is deliberate, documented and enforced.

The risk comes from sharing. A reporting database that holds customer identifiers, a file share used for general collaboration, a staging environment loaded with production extracts or a backup target that receives everything can each pull sensitive data onto an asset that was never hardened, monitored or access-controlled for it. These copies are hard to see because they are rarely recorded. Analytics jobs export tables, developers clone databases to test, and backups replicate whole volumes. Before you can segment anything, you need to know where sensitive data actually lands, which is why the data inventory and architecture diagrams come first. Confirm with the CIS Controls Assessment Specification, which lists those two Safeguards as prerequisites for measuring 3.12, that your evidence chain starts there.

Start with a short decision list: which sensitivity levels from your data management process map to which environments, which assets are approved for each level, and which copy paths (backups, analytics, test data, logs) must be blocked or explicitly approved. Then test the boundary. Pick a sensitive data type, trace its flows and confirm no approved-for-lower-sensitivity asset holds it. The CIS Controls Navigator links this Safeguard to ISO/IEC 27001:2022 Annex A 8.20 and 8.22, SOC 2 CC6.7 and PCI DSS v4.0 requirements 1.4.1 and 1.4.4, so the same segmentation evidence may serve several audits. Confirm each mapping against the current Navigator version before you rely on it.

Which systems, data and teams fall under the segmentation scope

Safeguard 3.12 is only as large as the scope you draw around sensitive data. The cards below cover the decisions that most change the work: which sensitivity levels trigger separation, which asset classes and accounts count, and which third parties sit inside the boundary.

Sensitivity levels that trigger separation

Start with the sensitivity levels defined in your data management process under Safeguard 3.1. Decide which levels require their own processing and storage, for example a confidential tier, and which can share assets with public or internal data. Every level you add to the separated set multiplies the number of systems that need their own home, so agree the list with data owners before any architecture work begins. Record the decision so assessors can trace it.

Servers and databases holding sensitive records

Production servers and databases that store or process sensitive data are the core of the scope. Each one must be identified in the data inventory from Safeguard 3.2 and placed on a segment or host dedicated to its sensitivity level. Shared database clusters and multi-tenant application servers often pull the scope wider than expected, so check whether a single host ever serves both sensitive and lower-sensitivity workloads.

File shares, endpoints and backups

File shares, employee endpoints and backup repositories frequently hold sensitive copies without anyone recording them. Check whether sensitive folders sit on general-purpose file servers, whether laptops used for sensitive work are also used for lower-sensitivity tasks, and whether backup targets are reachable from less protected networks. Each location that stores sensitive data counts toward scope, and each one needs an owner and a documented placement.

Development and test copies of data

Production data copied into development, test or analytics environments is a common gap. If those copies contain sensitive fields, the non-production environment inherits the sensitivity of the source and must be separated accordingly, unless the data is masked or synthetic. Ask engineering teams which clones exist, who can reach them and whether they run on assets shared with lower-sensitivity workloads.

Cloud accounts, subscriptions and SaaS tenants

Cloud accounts, subscriptions, projects and SaaS tenants are the usual boundary for separation, because they can hold different sensitivity levels in one organization. Map which accounts hold sensitive data, whether they share networks, identity providers or logging pipelines, and whether a shared service crosses the line. Confirm the provider's isolation features with the vendor before relying on them in the design.

Third-party processors and data owners

Service providers that store or process sensitive data sit inside the scope when they hold your data, even though you do not operate their systems. Ask for their hosting regions, tenancy model and sub-processors, and record them in the data flow documentation from Safeguard 3.8. Assign each data owner to approve placement decisions, because the owner who understands the sensitivity is often not the team that runs the infrastructure.

How an assessor tests the coverage measure for Safeguard 3.12

An assessor measures Safeguard 3.12 with one coverage metric that the CIS Controls Assessment Specification builds from three measures. The specification lists Safeguard 3.2 (the data inventory) and Safeguard 12.4 (architecture diagrams) as prerequisites, because the measurement typically needs the data those two safeguards produce. Before testing begins, confirm that the inventory records a sensitivity level for each data class and that the diagrams show where each processing and storage asset sits. If either source is missing or out of date, the assessor has nothing reliable to trace against, and the coverage result will not hold up.

The assessor starts with each sensitive data class in the inventory and follows it to every asset that processes or stores it, including databases, application servers, file shares, backup targets, analytics platforms and endpoints. For each asset, they compare its sensitivity tier with the most sensitive data it holds, using the architecture diagrams to confirm placement. Exceptions are the findings that matter most: a sensitive class on an asset meant for lower-sensitivity data, a shared host with no documented separation, or a copy created by an export or a test environment. Illustrative example: a customer record table replicated into a reporting database on a general-purpose server would count as an exception until the copy is moved or its placement is formally documented.

The specification defines what to measure, and the method for measuring it is your organization's to document. Write down how you define sensitivity tiers, which asset attributes place an asset in a tier, how exceptions are recorded, who approves an accepted exception and how often the trace is repeated. Agree the method with your assessor before fieldwork, since an undocumented method is difficult to evidence. Keep the trace output, the exception log and the approval records together, and review the CIS Controls Assessment Specification for Safeguard 3.12 so the method maps directly to each measure.

What assessors ask for and where segmentation gaps show up

This table lists the test areas an assessor is likely to examine for Safeguard 3.12, the evidence each area usually produces, and the gaps that appear most often. Read it as a pre-assessment checklist, since each row traces back to the data inventory and architecture diagrams that feed the coverage metric. The main takeaway is that segmentation is tested through the data inventory, so an incomplete inventory creates gaps even when the network separation is sound.

Test area	Evidence an assessor expects	Where gaps usually show up
Inventory-to-asset mapping	Data inventory entries for each sensitive data set, linked to the asset inventory and software inventory entries for every system that stores or processes it	Data recorded at the database level but not at the hosts, containers, analytics jobs or backup targets that copy it
Sensitivity tier per asset	A documented sensitivity level for each asset that matches the classification in the data management process	Assets with no tier, or a tier lower than the most sensitive data they hold
Diagram accuracy	Architecture diagrams showing trust zones, processing locations and storage locations, with an owner and a review date	Diagrams that omit cloud accounts, replicas or data pipelines, or that show separation the live configuration does not enforce
Separation of sensitive and lower-sensitivity assets	Firewall rule exports, security group or network policy configurations, account or tenant structure and access lists showing how sensitive stores are reached	Broad any-to-any rules, shared administrator accounts across zones, or shared build runners and test environments that touch sensitive data
Exception handling	A register of each exception with the asset, the business reason, compensating controls, the approver, the approval date and an expiry date	Exceptions with no expiry, informal approvals, or exceptions that never reach the data inventory
Sampling of assets	A complete population list from which the assessor selects the sample, plus evidence of how that list was built	Population lists drawn from production only, leaving out development, test, backup and disaster recovery assets
Coverage metric calculation	The worksheet showing population counts, how the three CAS measures were scored, and how they combine into the coverage result	Counts taken from one inventory source, or numerator and denominator defined differently from one review to the next
Confirmation of the three measures	A written reading of the three measures in the CIS Controls Assessment Specification for v8.1, agreed with the assessor before fieldwork	Teams scoring against their own interpretation of the measures, which the assessor may score differently

How to implement segmentation by sensitivity in six steps

This sequence turns the Safeguard 3.12 requirement into a documented data map, a tier rule and enforced boundaries, so an assessor can see that sensitive data never runs on assets meant for lower-sensitivity data.

Confirm sensitivity levels from the data management process
Start from the sensitivity levels already defined in the data management process under Safeguard 3.1, which the organization owns and approves. Confirm that each level has a plain definition, an owner and handling rules, and that the levels are the ones your teams actually use. Output: an approved list of sensitivity levels with the handling rule for each. You know this step is done when every level can be applied to a data type without debate.
Build or refresh the data inventory
Build or refresh the data inventory under Safeguard 3.2, recording where each data set lives, which system owns it and what sensitivity level it carries. Include databases, file shares, object storage, SaaS platforms and backups, since those are common places where sensitive data ends up on the wrong asset. Output: an inventory that lists each data store with its sensitivity level. You know this step is done when the inventory can be reconciled against the asset inventory from Control 1.
Map each data class to the assets that hold it
For each data class, record every asset that stores, processes or transmits it, including application servers, analytics jobs, development and test environments and endpoints used for support. Flag any asset that holds data above its intended tier. Output: a mapping table from data class to assets, with a column for the highest sensitivity level each asset is permitted to handle. You know this step is done when every asset in the mapping has a stated tier.
Define tiers and the rule against lower-tier processing
Define the processing tiers, typically one tier per sensitivity level or a small set of zones, and write the rule that an asset assigned to a lower tier must never process or store data from a higher tier. Specify who approves a change of tier for an asset. Output: a short tier standard that names each tier, its permitted data classes and the approval path for exceptions. You know this step is done when the rule can be tested against the mapping from the previous step.
Enforce the boundaries with network, account and platform controls
Enforce each tier with the controls the environment already supports: network segmentation and filtering between zones, separate administrative accounts and access groups per tier, and platform settings such as separate databases, namespaces or clusters. Open-source options include OPNsense aliases and rules that restrict traffic by source, destination, port and protocol, and rules can be logged for review. Confirm each option with the vendor and your own environment. Output: configuration records showing that the boundary exists in each system. You know this step is done when a test shows a lower-tier asset cannot reach higher-tier data stores.
Document architecture diagrams and exceptions
Document the architecture diagrams under Safeguard 12.4, showing the tiers, the boundaries between them and the data flows that cross them. Record every exception to the tier rule with a named owner, a justification, a compensating control and a review date set by the organization. Output: current diagrams, an exception register and a review record. You know this step is done when an assessor could follow a single sensitive data set from its store to its consumers using only the documents.

Evidence that shows sensitive data stays on its own tier

Safeguard 3.12 is only as credible as the records behind it. The cards below cover the artifacts an assessor would pull to test whether sensitive data is kept off lower-tier assets, and how each one is kept current between audits so it reflects the environment as it is today.

Data inventory with sensitivity and location

The data inventory is the starting point, since Safeguard 3.2 is a prerequisite for measuring 3.12. Each data store should record its sensitivity label, owning system, hosting asset and tier. Check that every store holding sensitive data names a tier that matches the data management process. Refresh it when new stores appear, and review the whole inventory at least annually, as the data management process requires.

Current architecture diagrams with tier boundaries

Architecture diagrams show where each tier starts and stops. Safeguard 12.4 is the prerequisite that typically produces them. Draw the boundaries as they run today, including network zones, cloud accounts, clusters and backup targets. Assessors compare diagrams against the inventory and firewall rules, so any mismatch becomes a finding. Tie each diagram revision to a date and an owner.

Asset-to-tier mapping

This register lists every enterprise asset with the highest sensitivity tier it is approved to process. It is the record that proves a lower-tier server, endpoint or workspace is not used for sensitive workloads. Confirm that each asset has one tier, that shared platforms are labeled at the highest tier they host, and that retired assets are removed. Update it whenever an asset changes role.

Firewall and segmentation rule exports

Export the active rule sets from firewalls, security groups and network policies that separate tiers. Platforms such as OPNsense can export rules with aliases that group addresses by tier, and logging on each rule match shows what is actually passing. Check that deny-by-default is in place between tiers and that no rule permits lower-tier sources to reach sensitive stores. Export on a schedule and keep the dated copies.

Platform configuration exports

Configuration exports from databases, storage services, container platforms and identity systems show whether data placement is enforced in the platform itself. Look for separate namespaces, buckets, databases or tenants per tier, and for access bindings that match the tier. Record the export command and version used so the evidence can be reproduced. Store exports in version control to show history.

Exception register with approvals

Some workloads will need a temporary exception, such as a shared analytics job reading sensitive data from a lower-tier cluster. Each exception needs a documented reason, compensating controls, a named approver, and an expiry date. Assessors look for exceptions that never expire. Review open exceptions at each data management review, and close those whose business reason has ended.

Change records for tier placement

Change tickets show how new systems and moves between tiers were approved and verified. Each record should name the data affected, the source and target tiers, the rule or configuration changed, and the post-change check. Confirm that changes to segmentation rules and asset tiers pass through the same approval path. Reconcile change records against the inventory and mapping at least once a year.

How Coraza and OPNsense can enforce and evidence tier boundaries

OPNsense and Coraza turn part of a tier boundary into rules you can review, but only for traffic. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases let you group the address ranges that belong to each sensitivity tier, so a rule can read as "Restricted tier may accept connections only from the Confidential tier on port 5432" rather than a list of IP addresses. Enabling per-rule logging writes each match to the live log view, which gives an assessor a trail to sample when testing whether sensitive data paths stay inside their tier. Confirm that the rule-logging and alias features in your OPNsense version behave as described in the OPNsense rules documentation before you build evidence around them.

Coraza is an open-source web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it can sit in front of application tiers. It has integrations for Caddy, HAProxy, Traefik and Nginx, so the proxy that already routes requests to a lower-sensitivity application can carry the inspection policy for that tier. Its rulesets address attacks such as SQL injection, cross-site scripting and code injection. Coraza inspects HTTP requests and responses. It does not decide where a database lives, which host runs a batch job against sensitive records, or whether a backup of restricted data lands on a general-purpose volume.

Treat these tools as enforcement for the network and application edge, and pair them with platform controls for storage and processing. The separation itself depends on hypervisor or cluster placement, storage pools with separate encryption keys, separate database instances, and admin roles that cannot cross tiers. Ask your implementation partner and internal architects to map each tier to its firewall aliases, proxy routes and storage locations in the architecture diagrams, then test whether a lower-tier host can reach a higher-tier data store through any path the firewall does not cover. Confirm fit with your own environment, since the right split depends on your topology, your data types and the Safeguard 3.2 data inventory.

What meeting Safeguard 3.12 costs in money and effort

This table breaks down the cost components of meeting Safeguard 3.12 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to scope a quote and to see where self-hosted open-source tooling removes license spend while leaving design, evidence and review effort in place. No price figures are given because none are supplied for this Safeguard.

Cost component	Who is paid or who spends effort	One-time or recurring, and what drives it
Data inventory and architecture diagram upkeep	Internal data owners and architects; an implementation partner if scoped	Recurring. Drives: number of data stores, how often sensitivity labels change, and how many diagrams must show processing zones (Safeguards 3.2 and 12.4 are prerequisites)
Architecture redesign or workload migration	Internal platform engineers; implementation partner for fixed-scope design work	Mostly one-time. Drives: how many workloads share hosts or networks today and how much must move to sensitivity-specific zones
Firewall and platform engineering	Network and platform engineers; implementation partner for self-hosted firewall and segmentation builds	One-time build, then recurring rule review. Drives: number of zones, rule count, and how many cross-zone flows must be justified
Licenses for named open-source tools	No license fee for the tools named (for example OPNsense under BSD-2-Clause, Coraza under Apache-2.0); staff time still applies	Recurring cost removed for the licenses. Confirm current license terms with each vendor before relying on them
Infrastructure for separate zones	Cloud provider or data center operator, depending on where the client hosts the platform	Recurring. Drives: number of isolated environments, redundancy needs, and whether sensitive zones need dedicated hardware
Evidence upkeep	Internal compliance and security staff; implementation partner if retained	Recurring. Drives: how often assessors sample rule sets, flow records and access logs, and how much evidence is exported per cycle
External review and auditor sampling	Independent auditor or assessor, paid by the organization	Recurring per assessment cycle. Drives: scope of in-scope zones and the number of samples the assessor selects. Ask the auditor for the sampling approach in writing

Who owns segmentation, who can help and where the auditor stops

Your organization owns Safeguard 3.12. The Safeguard asks the enterprise to decide which data is sensitive, which assets may process it, and to keep those assets separate from assets meant for less sensitive data. Those decisions depend on business context that an outside party cannot judge for you, so they should stay in-house even when a partner does the technical work.

Sensitivity tiers: Your data owners set the sensitivity levels and the rules for each tier, aligned with the data management process under Safeguard 3.1.
Data inventory: You decide which data stores are in scope and keep the inventory current, since Safeguard 3.2 is a prerequisite for measuring 3.12.
Asset assignment: Named owners approve which systems may hold each tier and accept exceptions in writing.
Architecture diagrams: Your architects maintain the diagrams that show where each tier sits, as described under Safeguard 12.4.
Ongoing review: Your staff review new projects and vendors against the tiers before data moves.

Before engaging anyone, confirm that a named owner can sign off the tier model, because an assessor will ask who made those decisions.

Where segmentation by sensitivity usually fails

Segmentation by sensitivity rarely fails in the primary system, which teams design deliberately. It fails in the copies, exports, shared accounts and paperwork that appear around it over time. Each card below names one place where sensitive data leaks into a lower-sensitivity asset, and the check that catches it.

Backups and replicas on lower tiers

Backup sets and database replicas often inherit the storage tier of the job that created them, not the sensitivity of the data they hold. A nightly snapshot of a restricted customer database may land in a general-purpose bucket with broader access and weaker retention rules. For Safeguard 3.12, check each backup target and replica against the sensitivity of its source, and confirm the data inventory records where those copies live. Fix: assign each backup and replica the classification of its source and store it in a tier that meets that level.

Dev and test copies of production data

Teams often clone production databases into development or test environments to reproduce defects. Those environments usually have looser access, fewer logs and developers who do not hold rights to production data. Ask whether each non-production environment contains live sensitive records, and whether the data inventory lists those copies as separate data stores. Fix: use masked or synthetic data in lower environments, and keep any unavoidable copy on infrastructure at the same sensitivity level as its source.

Analytics exports and spreadsheets

A report pulled from a restricted system into a shared drive, a BI workspace or an email attachment moves sensitive fields onto assets built for general use. The export often outlives the question it answered. Review which reporting tools can query sensitive tables, and which export paths exist from those tools. Fix: restrict export rights on sensitive datasets, and route approved extracts to storage that carries the same sensitivity label.

Shared administrator accounts across tiers

A single administrator account that manages both a low-sensitivity file server and a restricted database lets one identity reach data it does not need for its role. Segmentation of storage then depends on the discipline of one login. Check which accounts hold rights in more than one sensitivity tier, and whether their sessions are logged. Fix: give each tier its own administrator account, with separate credentials and a record of which tier each account can reach.

Stale architecture diagrams

Diagrams that show a segregated design become misleading once a service is added, moved or re-hosted. Assessors use architecture diagrams as the reference for how data is separated, so a stale diagram can hide a shared path that no longer matches the design. Compare each diagram with current network rules, cloud accounts and data flows. Fix: tie diagram review to change management, so each change that moves a data store or service updates the diagram and the inventory together.

Inventory missing data classes

A data inventory that lists customer records but omits logs, support attachments, model training sets or message archives leaves those classes outside any segmentation decision. Sensitive data frequently sits in these overlooked places. Compare the inventory against the systems in the asset inventory, and against the classes named in the data management process. Fix: add each missing data class to the inventory with its sensitivity and location, then assign it to a tier before it is used.

Undocumented exceptions

Exceptions such as a temporary exporter, a vendor support account or a one-off integration often bypass the tier rules and are never recorded. Over time they become the normal path for sensitive data. Ask teams for a list of approved exceptions, each with an owner, a reason and an end date, and check whether any exception is absent from the diagrams. Fix: require a written, time-limited exception record for every cross-tier flow, and review the register at the cadence set in the data management process.

Questions buyers ask about Safeguard 3.12

How much effort does it take to segment data by sensitivity under Safeguard 3.12?

The effort depends on how many systems process sensitive data today and how far those systems are mixed with lower-sensitivity workloads. Most of the work sits in three places: confirming the data inventory and sensitivity labels that Safeguards 3.2 and 3.7 produce, drawing or correcting architecture diagrams that show where each data class is processed and stored, and then separating or fencing the assets involved. Ask for the effort split in any quote, because the diagram and inventory work is often larger than teams expect when no current inventory exists. Confirm the details with a scoped plan based on your own environment before committing budget.

Can our own team implement Safeguard 3.12 without outside help?

Yes, an enterprise can implement Safeguard 3.12 with its own staff, and the CIS Controls are free for any organization to use to improve its own cybersecurity. The organization owns the control, so internal teams need agreed sensitivity levels, an accurate data inventory, current architecture diagrams and people who can change network and platform configuration. Outside help is usually considered when those prerequisites are missing or when the team lacks capacity for segregation work. A partner can prepare systems and evidence, but the organization remains responsible for the decisions and the outcome.

Does Safeguard 3.12 apply to IG1 organizations?

No, Safeguard 3.12 is not an IG1 Safeguard. CIS assigns it to Implementation Groups 2 and 3, so organizations that have only adopted IG1 do not need to meet it to claim IG1 coverage. Organizations that handle sensitive data should still review whether the practice is needed for their risk, especially if IG2 or IG3 applies to them through regulation or contract. Confirm your Implementation Group assignment on the CIS Implementation Groups pages before scoping the work.

How long does Safeguard 3.12 take to implement?

The duration depends on the environment, not on a fixed figure. Timelines grow with the number of applications and data stores, the state of existing documentation, how many shared platforms mix sensitivity levels, and whether segregation requires hardware, cloud account or network changes. No duration is given here because none has been researched for this Safeguard. Ask for a timeline as part of a written, fixed-scope plan that lists the systems in scope, the deliverables and the dependencies on other Safeguards such as 3.2 and 12.4.

What does the work need from our client team?

The work needs named owners from several functions. Data owners must confirm sensitivity levels and which data sets belong to each level. Platform and network engineers must describe current processing and storage locations and carry out configuration changes. Application owners must confirm which workloads share assets, and security or compliance staff must agree the evidence the assessor will need. Expect to provide access to change records, cloud or data center accounts and existing diagrams. A written scope should name these people and the time they are expected to contribute.

Can a partner issue the Safeguard 3.12 assessment result?

No. A partner such as DeployOpen can plan, implement and document segmentation and prepare systems and evidence, but it cannot issue an assessment result or certificate. Only an independent assessor or certification body issues reports or certificates. CIS Controls Accreditation, run with CREST, is a separate program for CIS SecureSuite member organizations that provide CIS Controls services, so ask any provider whether it holds that accreditation before relying on its claims.

Which open-source tools help produce evidence for Safeguard 3.12?

Tools help enforce boundaries and keep records, but they do not decide sensitivity levels. A web application firewall such as Coraza can protect applications that handle sensitive data, and an OPNsense packet filter can restrict traffic between zones by source, destination, port and protocol, with rule-match logging for review. Confirm each platform's current capabilities against its own documentation, and map the resulting rules and logs to the data inventory and diagrams that the assessment specification expects.

How DeployOpen scopes and prepares segmentation evidence

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Safeguard 3.12, that means working with your team to define which platforms, databases, storage tiers and processing jobs handle each sensitivity level, then preparing the systems and records an assessor will review. DeployOpen prepares that material. It does not decide your sensitivity levels, own your controls, or issue any report or certificate. Those decisions and the assessment remain with your organization and an independent assessor.

Engagements are fixed-scope. Before work starts, the written agreement sets out which environments are in scope, which sensitivity tiers and data stores are covered, the deliverables (for example, the segmentation diagram, the mapping from the data inventory to each asset class, and the access rules that enforce separation), and the timeline. Ask for the scope to name the systems that will be checked against the three measures in the assessment specification, and confirm in writing who signs off each deliverable on your side. Changes to scope are priced in writing before they are carried out.

Ongoing support is available as a retainer for work that continues after the first delivery, such as reviewing the architecture diagrams when a new workload is added, re-checking that sensitive data has not moved onto lower-tier assets, and keeping the evidence current for each assessment cycle. Confirm with your provider which of these activities the retainer covers, how often reviews happen, and how change requests reach the team. Your own data owners should still approve any reclassification of data, since that decision drives everything the segmentation depends on.