What Safeguard 16.8 asks for and why separation is hard to prove
If your enterprise is in Implementation Group 2 or 3, Safeguard 16.8 applies to you and an assessor will expect to see that production and non-production systems are kept apart. The safeguard asks you to maintain separate environments for the two, so that development, test, staging and similar systems do not sit inside the same trust boundary as the systems that serve customers and process live data. CIS assigns the safeguard to the Network asset class and the Protect security function. The CIS Controls Assessment Specification defines what to measure for this safeguard, but it does not prescribe how to build the separation, so the design choices are yours to make and justify.
The risk is concrete. Test code that has not been reviewed can reach a live system through a shared deployment pipeline. Copies of production data can sit in a test database with weaker access controls than the source. A test environment with default credentials, relaxed firewall rules or a debug service exposed can become a route into production networks that share the same directory, DNS zone or administrative accounts. Each of these paths bypasses the protections the production environment depends on, which is why the separation has to hold in the network, in identity, in data and in the release process, not only in the architecture diagram.
Separation tends to drift after it is first set up. A firewall rule is opened for a one-off integration test and never closed. A service account used by a build server is granted rights in both environments for convenience. A developer copies a production dataset to reproduce a bug. Over months, the boundary that was clean at go-live becomes a set of exceptions no one has recorded. Before your assessment, confirm which environments exist, which network paths and credentials cross between them, who approves exceptions and where those approvals are logged. Those records, rather than the original design, are what usually prove the safeguard holds.
Which environments, data and teams fall under the separation
Safeguard 16.8 is only as strong as the boundary drawn around it. The decisions below determine which systems must be separated, which shared services cross the line, and which third parties touch non-production copies, so the boundary should be written down and assessed before the evidence is collected.
Defining production and non-production
Start with a written definition of what counts as production, based on who depends on the system and what data it holds, then classify every environment against it. Staging, UAT, performance, sandbox and developer environments each need a named classification. Ambiguous cases, such as a pre-production system that receives live customer traffic, are the ones assessors ask about. Confirm the classification list is approved and matches the asset inventory.
Shared networks and segmentation
Check whether non-production hosts share subnets, VLANs, load balancers or firewall zones with production. Separation on paper with flat routing between zones does not meet the intent of 16.8. Review the firewall rule sets that govern east-west traffic, and confirm which direction of access is permitted, such as deployment pipelines reaching production but not the reverse. Open-source firewalls such as OPNsense can enforce and log these zone rules.
Shared identity providers and admin accounts
A single directory that authenticates both environments can let a compromised developer account reach production. Decide whether identity is shared, and if it is, document which groups, roles and privileged accounts cross the boundary and why. Administrators who hold rights in both environments are a common exception that needs an approval record and a review cycle.
CI/CD pipelines and cloud accounts
Pipelines, artifact registries and infrastructure-as-code runners often hold credentials for production. Decide whether they sit inside the boundary, and if they do, restrict which branches and approvers can trigger production deployments. Separate cloud accounts or subscriptions are a common way to draw the line, but only if billing, service control policies and network paths are also separated. Confirm where each deployment credential is stored and who can read it.
Copies of production data for testing
Test datasets copied from production bring production data, and often its controls, into non-production systems. Decide whether such copies are permitted, and if so, require masking or synthetic substitution before the copy leaves production, plus the same access restrictions. Record each copy with its source, owner, location and deletion date. Illustrative example: a refreshed database clone that still holds customer identifiers is production data for scoping purposes.
Third parties hosting non-production systems
Outsourced development, testing and offshore support teams often run non-production systems outside your own infrastructure. Their environments may hold production-derived data or reach production networks through VPN or remote access. Include these providers in the boundary, confirm the contract terms that cover their access and data handling, and collect their environment inventories as evidence.
How an assessor tests environment separation
The assessor starts with the documented design. They expect a written description of each environment, what it hosts, which networks it sits on and which environments are allowed to talk to each other. They then check that the design matches reality by comparing diagrams against firewall rules, routing tables and cloud network configuration. The Assessment Specification defines what to measure for Safeguard 16.8, but the method is left to the assessor and the organization, so the assessor will usually agree the approach with you before testing begins.
- Environment inventory: a list of production, staging, test and development environments with owners, hosting locations and purpose.
- Network diagrams: current diagrams showing segmentation and every permitted path between environments.
- Rule review: exported firewall or security group rules, with a sample traced back to a business reason.
- Blocked path testing: attempts from a non-production segment to production addresses, with logs showing the attempts were denied.
- Drift checks: evidence that diagrams and configurations were compared within the review period.
Check that the diagrams and the exported rules tell the same story. A mismatch between them is the finding an assessor is most likely to raise.
Separation fails quietly when the same people, service accounts or secrets work in both environments. The assessor looks for distinct identities per environment, separate administrative groups and secrets that cannot be read across the boundary. They sample accounts and check which systems each one can reach, then confirm that production privileges are granted through a documented approval path. The method is agreed with the assessor, who will want to see both the directory configuration and the access logs.
- Account listings: exports of users and service accounts per environment, showing no shared administrative identities.
- Group membership: role assignments for production and non-production, with approval records for production access.
- Secrets stores: evidence that production credentials are stored apart from non-production configuration.
- Cross-environment access tests: a non-production identity attempting production resources, with denied results.
- Access reviews: recent recertification of production access, including removal of unneeded accounts.
Ask whether any engineer holds production credentials for daily work. An assessor will test that claim against the logs rather than accept the answer.
The assessor follows a change from development to production and checks that the path is controlled. They expect a promotion process in which code and configuration move through non-production environments before reaching production, with approvals recorded in a system that cannot be edited after the fact. Sampling focuses on recent production changes, so the assessor can see whether each one passed through the stated route.
- Promotion pipeline: the documented stages and the gates between them, with the pipeline configuration as evidence.
- Sampled changes: selected production changes traced to build, test and approval records.
- Emergency changes: records of any change that bypassed a stage, with justification and after-the-fact review.
- Direct access logs: audit records of any manual edits made directly in production.
- Ticket linkage: change requests linked to the code or configuration release they authorized.
Review the emergency change records first. Their completeness often shows whether the promotion process is followed in practice.
Copying production data into test environments is a common way separation breaks down. The assessor will ask whether non-production systems hold real records, how that data got there and who can read it. They sample datasets and compare them with production sources, and they look for controls such as masking, synthetic data or approval before a copy is made. Where the organization allows production data outside production, the assessor expects the same protections to apply there.
- Data source inventory: a record of which non-production datasets originate from production and when they were copied.
- Masking or synthetic data procedures: documented methods for removing or replacing sensitive fields.
- Sampled datasets: a sample of test data inspected for real personal or payment fields.
- Copy approvals: records authorizing each production-to-test data transfer.
- Retention and deletion: evidence that copied datasets are removed when the test purpose ends.
Confirm with your assessor which data classes they will sample, because the answer determines how much masking evidence you need to prepare.
How to implement and document the separation
This sequence turns Safeguard 16.8 into a documented, testable state: every production and non-production system is inventoried and classified, boundaries and credentials are enforced, and changes move between environments only through controlled paths that leave evidence behind.
Inventory and classify every environment
Start by listing every production, staging, test, development and training environment, along with the applications, databases, data sets and third-party services each one touches. Classify each environment by the sensitivity of the data it holds and by whether it serves live users. The owner of the application and the security team sign off on the list. The output is an environment register that names each environment, its class, its owner and its data types. Confirm the register is complete by checking it against your cloud accounts, clusters, virtual machine hosts and CI/CD pipelines, since shadow environments often appear here first.
Set network and identity boundaries
Place production and non-production workloads in separate network segments, accounts, projects or clusters, and restrict traffic between them to the specific flows that are needed, such as a deployment service reaching a target. Apply firewall rules that deny by default and log each allowed flow. Use separate identity realms or directory groups so that a user with access to a test system does not inherit production rights. The output is a boundary diagram and a rule set that the security team can review line by line, with each rule tied to a documented business reason.
Separate credentials and deployment paths
Give each environment its own secrets store, service accounts, API keys and database credentials, so no value works in more than one environment. Build separate deployment pipelines or protected release stages for production, with approval controls that developers cannot bypass. Keep production secrets out of source code, build logs and non-production configuration files. The output is a credential inventory per environment and a pipeline definition that shows which identities can deploy where, which you can test by attempting a cross-environment login and recording that it fails.
Control promotion of code and data
Define how a build moves from development to test to production, and state which artifacts may move: compiled packages, container images, configuration and, where permitted, data. Require that production uses the exact artifact tested earlier, identified by a version or digest. Prohibit copying production data into lower environments unless it is masked, tokenized or approved under the data protection policy. The output is a promotion procedure with its approval gates and a sample release record that links a change request, the tested artifact and the production deployment.
Monitor for drift and unauthorized crossing
Configure monitoring that detects environment drift, such as a production configuration that differs from its approved baseline, a non-production identity that touches production resources, or a cross-environment network connection that no rule allows. Send these events to the central log platform and set alerts for the security team. Review the alerts on a schedule the organization documents. The output is a set of alert definitions, a sample of triggered and resolved events, and a review log that shows who examined each alert and what action followed.
Document each step and retain the output
Assemble the artifacts from the previous steps into one controlled document set: the environment register, boundary diagrams, firewall and identity rule exports, credential inventory, promotion procedure, sample release records and drift review logs. Assign an owner for each document and a review cycle. Store them in a version-controlled repository or management system with change history. An independent assessor will typically test whether the documented separation matches what the systems do, so confirm that a sample of the documents can be traced to live configuration and recent change records.
Evidence that shows the separation holds between audits
An assessor testing Safeguard 16.8 looks for proof that production and non-production stay apart on any given day, not only at the moment of review. The cards below cover the records that prove it and the recurring exports and reviews that keep them current, so the evidence is not rebuilt when an audit begins.
Environment inventory
A current list of every production and non-production environment, its owner, its hosting location, and the systems and data it holds. Assessors use it as the starting point for every other artifact, so any environment missing from it is a gap. Export the inventory on a fixed schedule, record who approved each change, and compare it against the cloud account list and the network diagrams to find environments nobody documented.
Network diagrams and firewall rule sets
Diagrams show where the boundary between production and non-production sits, and firewall rules show what is allowed across it. Export the rule set for each boundary firewall and keep the logged rule matches for review, since a rule that allows traffic in one direction only is often the finding. Confirm that the rule log is retained long enough to cover the audit period and that the aliases used for address groups still match the diagram.
Separate account and credential records
Production and non-production should use separate directories, administrator groups and service credentials, so a developer's test login cannot reach live data. Keep a record of which accounts exist in each environment, who holds them, and when secrets were last rotated. Review that no credential is shared across the boundary, because a single reused password undoes the separation on paper.
Promotion and change tickets
The record of how code and configuration move from non-production into production shows whether the separation is enforced in practice. Each promotion should link to a ticket with the approver, the tested build and the rollback plan. Ticketing tools such as GLPI or Zammad can hold this record, and a periodic query for production changes that lack a linked approval is a useful check before an assessor finds one.
Production access reviews
Access to production should be granted to a small, named group and reviewed on a set schedule. Each review should confirm that every account still needs its role, that no developer holds standing production rights without a reason on record, and that accounts for departed staff are removed. Keep the signed review and the list of changes it produced, because a review with no recorded outcome is hard to defend.
Test data handling records
Non-production systems often hold copies of live data, which can weaken the separation if the copying is undocumented. Keep a record of each data copy: its source, the approval, the masking or anonymization applied, and the date it was deleted. Check these records against the environment inventory each quarter, since a forgotten test database with real customer records is one of the more common findings in this area.
What meeting Safeguard 16.8 costs in money and effort
This table breaks down the cost components of keeping production and non-production environments separate for Safeguard 16.8, marking each as one-time or recurring and naming who is paid. Use it to structure a written quote, since no price figures are supplied for this safeguard and costs depend on your own environments and scope.
| Cost component | Who is paid or who carries the effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Environment and network design | Internal architects or an implementation partner designing the separation boundaries, VLANs, subnets, accounts or projects | One-time, with revisions when topology changes | Number of applications and data classes, and whether production and test already share networks or identity systems |
| Tooling and licenses | Vendors for commercial firewalls, cloud controls or management platforms; no license fee for open-source components such as OPNsense or GLPI | Commercial licenses recur; open-source software carries no license fee but still needs hosting and staff time | Choice of commercial versus open-source tooling, and the number of environments that each need their own controls |
| Engineering time for separation and promotion pipelines | Platform engineers and developers building deployment pipelines, credential separation and approval gates | One-time build, then recurring maintenance as applications change | Degree of automation, number of release paths and how often promotion rules change |
| Ticketing and change records | Operations staff maintaining change records that show what moved between environments | Recurring | Release frequency and whether a helpdesk or ITSM tool already records changes |
| Evidence upkeep | Internal compliance or security staff collecting configuration exports, access reviews and promotion logs | Recurring, usually each assessment cycle and after significant changes | Whether logs and configurations are collected automatically or gathered by hand before each review |
| External review or testing | Independent testers or consultants checking that test data and credentials do not reach production | Periodic, tied to scope and assessment needs | Number of environments in scope, and whether testing covers only the boundary or also the data flows |
| Auditor sampling | The independent auditor or assessor, under an engagement agreed with the organization | Per assessment cycle | Number of environments, change volume and how quickly evidence can be produced on request |
Who owns the separation and who can help build it
The organization owns Safeguard 16.8. Its leadership decides what counts as production, which non-production environments exist, who may move code and data between them, and what exceptions are allowed. Those decisions belong in a written environment standard that the security and engineering leads approve. Day-to-day ownership usually sits with the platform or IT operations team, with application owners accountable for their own release paths.
- Environment inventory: a current list of every production, staging, test and development environment, with its owner, network location and data classification.
- Access rules: named roles for who can deploy to production, who can read production data, and who can change the boundary controls between environments.
- Promotion path: a documented route for code and configuration, from non-production to production, with approvals recorded.
- Exception register: each shared credential, copied dataset or cross-environment connection, with an owner, a reason and a review date.
- Monitoring owner: a named person who reviews boundary logs and drift reports.
Before engaging anyone outside the organization, confirm that internal owners can explain how each environment is separated and who signs off on changes to that separation.
An implementation partner can design and build the separation, configure the self-hosted platforms that enforce it, and prepare the evidence an assessor will request. In practice, DeployOpen-style work covers network segmentation, firewall and web application firewall rules, separate identity realms or projects, deployment pipeline gates, and the logging that records every boundary crossing. The partner does not decide the organization's risk acceptance and does not sign off on whether the control works.
- Environment build: provisioning separate networks, accounts or clusters, with the boundary rules written as code where the platform supports it.
- Pipeline gates: configuring promotion steps that block unreviewed artifacts from reaching production.
- Evidence preparation: exporting rule sets, change tickets, access reviews and log samples in a form the assessor can sample.
- Documentation: writing the environment standard drafts, network diagrams and runbooks that the organization then adopts.
- Knowledge transfer: training the internal team to operate and audit the boundary after handover.
Ask whether the partner's scope names the environments, the platforms and the evidence set, and whether the organization keeps administrative control of every system after handover.
The independent assessor tests whether the separation is in place and operating, and states a conclusion. Depending on the framework, that assessor may be an external auditor, a certification body, a qualified security assessor or another accredited firm. Only that party issues reports, attestations or certificates. Where the assessor is also the party that designed the controls, its independence is compromised, so the roles must stay apart.
- Walkthrough: the assessor asks how environments are defined and how promotion works, then compares the answers with documentation.
- Sampling: the assessor selects recent changes or access grants and traces each back to an approval and a logged event.
- Configuration testing: the assessor reviews firewall and access rules to confirm that production and non-production paths are blocked as documented.
- Exception review: the assessor checks whether each exception was approved, time-limited and reviewed.
- Reporting: the assessor records findings and an opinion. The organization does not write its own conclusion.
Confirm with the assessor which evidence formats it accepts, and whether the partner that built the environments may hand over evidence directly or must route it through the organization.
Organizations commonly outsource the parts that need specialist build capacity and repeatable documentation: the initial environment design, the boundary and pipeline configuration, the evidence export, and periodic reviews of rule sets. They usually keep the policy decisions, the approval workflow and the operation of production. Independence draws the line at the point where a party would judge its own work.
- Typically outsourced: environment build, infrastructure as code, pipeline gate setup, log pipeline configuration and evidence packaging.
- Typically retained: the environment standard, access approvals, exception decisions and day-to-day production changes.
- Never delegated: the conclusion on whether Safeguard 16.8 is met, which belongs to the independent assessor.
- Contract terms: statements of work should state deliverables, the environments in scope, handover dates and who holds administrative credentials at the end.
- Ongoing support: a retainer can cover rule reviews and upgrades, but it should not replace the organization's own periodic access and change reviews.
When requesting a quote, ask the partner to list which evidence it will produce and which items remain the organization's responsibility.
Where separation usually breaks and how to close each gap
Separation between production and non-production rarely fails in one dramatic step. It erodes through shared credentials, copied data, shared build infrastructure, forgotten firewall rules and changes that move without a trail. Each card below names one gap an assessor is likely to probe under Safeguard 16.8, with the closing action that leaves evidence behind.
Production credentials reused in test
Test applications often start with the database passwords, API keys or service accounts copied from production during an early build. The gap is easy to miss because the test system works. Close it by issuing separate credentials per environment, storing them in distinct secrets stores, and checking that no production secret resolves in a non-production configuration. Ask for a list of service accounts with the environments each one can reach, and confirm that the list matches what the system actually does.
Unmanaged test copies of production data
A test environment that holds a restored copy of production data inherits the production sensitivity, but it often lacks production monitoring, access reviews and patching. Close the gap by defining whether production data may enter non-production at all, requiring masking or synthetic generation before any copy is loaded, and placing each copy on the inventory with an owner and a deletion date. An assessor will ask who can log in to that copy and when it was last refreshed.
Shared CI runners with production access
Build and deployment runners that serve both test and production pipelines can carry deployment keys, cloud roles or network paths into the wrong environment. A job written for staging can reach production if the runner trusts both. Close the gap by using dedicated runners or pipeline identities per environment, limiting production deployment to protected branches with approval, and logging each job's target. Check the runner configuration, not only the pipeline definition.
Undocumented firewall exceptions
Troubleshooting rules, temporary openings between test and production subnets, and permissive aliases often outlive the incident that created them. Each one weakens the boundary the Safeguard relies on. Close the gap by requiring a ticket and an expiry date for every cross-environment rule, reviewing the rule base on a schedule, and logging rule matches so the team can show which traffic actually crossed. Firewall rule exports and their change tickets are the evidence to keep.
Promotion without records
When code or configuration moves into production through an informal copy, a manual edit or an untracked hotfix, the team cannot show that the change was tested in a separate environment first. Close the gap by making promotion a traceable step: each release record names the test evidence, the approver and the artifact deployed, and emergency changes go through the same record after the fact. Assessors commonly sample recent production changes and ask for this chain.
Questions buyers ask about Safeguard 16.8
How much effort does it take to separate production and non-production?
The effort depends on how many systems, networks and data flows sit on each side of the boundary today, so no single figure applies to every enterprise. Most of the work is one-time design and cleanup: documenting which environments exist, removing production data copies from development and test, creating separate accounts, networks and credentials, and building the change path between them. Recurring effort is smaller but never zero, because each new system, vendor connection or shortcut must be checked against the boundary. Ask any partner for a written scope that lists the environments, the number of applications and the integrations in each, because those three items drive the quote more than anything else. Treat any estimate given before that inventory exists as a guess.
Can an in-house team separate environments without outside help?
Yes, an in-house team can do this if it has the cloud, network and identity skills, time to run the work alongside normal delivery, and the authority to change how developers and operators access systems. Teams often struggle less with the technology than with the habits: shared credentials, production database copies used for testing and emergency changes made directly in production. An outside implementation partner can help by preparing the environments, writing the access and change procedures and collecting evidence, while the organization keeps ownership of its controls. Independent assessors, not the partner, decide whether the result meets the requirement.
How long does preparation usually take for this safeguard?
No researched duration is available for this safeguard, so confirm timelines with the partner against your written scope rather than relying on general estimates. Timing depends on how many applications share infrastructure, how mature your change management is and whether production data must be masked before reaching lower environments. Ask for milestones that separate inventory, design, environment build, data handling, access changes and evidence collection, because a delay in any one of them moves the whole plan. If a compliance deadline applies, work backward from the date the assessor or customer needs to see evidence.
What does the organization need to provide for the work?
The organization needs to supply accurate system inventories, named owners for each application, access to cloud or data center accounts, and decisions on which environments are required. It must also provide the current change process, identity provider details and any data classification it already maintains, since that shapes how production data may be copied. Expect to supply people who can approve changes to firewalls, routing and deployment pipelines. Without these inputs, the partner can only produce a design, not a working separation with evidence behind it.
Do organizations in Implementation Group 1 have to meet Safeguard 16.8?
No. CIS Controls v8.1 places Safeguard 16.8 in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. IG1 organizations still benefit from keeping development and production apart, and a regulator or customer may require it for other reasons, but the CIS Controls themselves do not assign this safeguard to IG1. Confirm your Implementation Group from the CIS Controls Implementation Groups pages before scoping, because the group determines which Safeguards your assessment would test.
How does Safeguard 16.8 map to ISO/IEC 27001:2022 Annex A 8.31?
The CIS Controls Navigator maps Safeguard 16.8 to ISO/IEC 27001:2022 Annex A control 8.31, which covers separating development, test and production environments. The mapping means evidence that shows separation for one framework can often support the other, but it does not make the two requirements identical. Check the Navigator entry and the ISO text in your own licensed copy before claiming coverage, and confirm with your certification body how it will test the control. The CIS Controls Navigator is the natural starting point for that check.
How does Safeguard 16.8 map to PCI DSS v4.0 requirement 6.5.3?
The CIS Controls Navigator maps Safeguard 16.8 to PCI DSS v4.0 requirement 6.5.3, which relates to separating pre-production environments from production and keeping them apart. Because payment account data must never flow into test environments, the same separation evidence supports both frameworks, but a QSA must still judge your scope and controls. Confirm the mapping against the PCI DSS text you hold, and document how production data is excluded from lower environments, since that is the point most often questioned.
What evidence shows that the separation actually holds?
Assessors look for a documented environment inventory, network and account boundaries, access reviews showing who can reach each side, change records proving that code moves through approved paths, and proof that production data is not copied into non-production without controls. Useful artifacts include firewall rule exports, identity group listings, deployment pipeline logs and ticket records from helpdesk tools such as GLPI or Zammad. Tools such as OPNsense rule logs and Coraza web application firewall rules can show segmentation and attack filtering at the boundary. Confirm with your assessor which samples they will pull, because the CIS Assessment Specification defines what to measure, not how.
How DeployOpen separates environments and prepares evidence
DeployOpen starts with a written scope before any separation work begins. The scope names which systems are production, which are non-production, which network segments and accounts each environment uses, and who approves changes that cross the boundary. Because most engagements are fixed-scope, the deliverables and timeline are agreed in writing first, so the client knows exactly which environments are being built, hardened and documented. Our engagement team then implements the separation inside the client's own cloud accounts, data centers or air-gapped networks, so the client keeps ownership of the infrastructure and of the controls that run on it. Where the client's network already uses an OPNsense firewall, the rules that keep traffic between environments can be written with aliases for each environment's address range and logging enabled on every rule match, so the boundary is enforced and visible in one place.
The evidence an assessor will request for 16.8 is mostly configuration and records, not narrative. Expect to produce an architecture diagram that shows each environment and its permitted paths, exported firewall and routing rules, separate identity and access groups for each environment, and change tickets that show production changes passed through the approved route. DeployOpen prepares these artifacts and runs a walkthrough so the client's staff can explain them. Confirm with your assessor how they want the evidence packaged and how far back they want logs to reach, since those requirements are set by the assessment, not by the implementation partner. Also confirm which of your applications the separation applies to, because the CIS Controls Assessment Specification defines the measurement for 16.8 and your scope decisions determine what that measurement covers.
DeployOpen does not issue audit reports, attestations or certifications. An independent auditor, assessor or certification body reviews the evidence and decides whether the Safeguard is met for your organization. Before you contract for implementation or evidence preparation, ask for the written scope, the list of deliverables, the evidence each deliverable produces, and the roles that remain with your team after handover. Ask who will maintain the rules and change records once the engagement ends, and whether ongoing support is needed through a retainer. Those answers tell you whether the separation will still hold, and still be provable, at the next assessment.
