AC-6(4): Separate Processing Domains

AC-6(4) requires you to create separate processing domains (practical isolation boundaries) so you can grant privileges more precisely and prevent broad access from spanning unrelated environments. Operationally, define your domains, map roles to each domain, enforce isolation with technical controls, and retain evidence that access is constrained by domain. ¹

Key takeaways:

• Define “processing domains” as real isolation boundaries (tenants/accounts/VPCs/clusters/segments), not just folders or tags.
• Tie privilege grants to domains so high privilege in one domain does not automatically carry into another.
• Keep assessor-ready evidence: domain inventory, access mappings, configs showing isolation, and review records. ²

AC-6(4): separate processing domains requirement sits under NIST’s least privilege family and pushes you toward a simple outcome: privilege should be granted within the smallest operationally meaningful boundary. If your admins, developers, support staff, or third parties can “see everything” across environments because everything shares the same control plane, you cannot allocate privileges with the granularity AC-6(4) expects. ¹

For most teams, the fastest path is to formalize domains you already have implicitly: production versus non-production, regulated versus non-regulated data, internal corporate IT versus customer-facing systems, and separate tenants for different customer populations. Then you make the boundary real using cloud accounts/subscriptions, network segmentation, cluster separation, and separate identity and access management scopes where feasible. The point is not to multiply environments without reason; it’s to reduce blast radius and prevent privilege accumulation across unrelated workloads.

This page tells a Compliance Officer, CCO, or GRC lead exactly how to translate AC-6(4) into scoping decisions, implementation steps, and audit-ready evidence, without getting stuck in theoretical definitions. ²

Regulatory text

Requirement: “Provide separate processing domains to enable finer-grained allocation of user privileges.” ¹

Operator interpretation (what you must do):

• Establish discrete “processing domains” where access decisions can be scoped and constrained.
• Ensure privilege assignments are made per-domain (or are technically constrained to a domain), so elevated access in one domain does not automatically grant the same power elsewhere.
• Be able to show an assessor the domain boundaries, how access is allocated within them, and that the boundaries are enforced in practice. ²

Plain-English interpretation

A processing domain is an isolation boundary that changes what a user can do. If the boundary does not actually constrain access, it is not a processing domain for AC-6(4) purposes.

Common “separate processing domain” patterns that usually satisfy the spirit of AC-6(4) when implemented correctly:

• Separate cloud accounts/subscriptions/projects for production, staging, development, and corporate IT.
• Separate Kubernetes clusters (or at least separate control planes) for production versus non-production.
• Separate VPCs/VNETs/segments with tightly controlled routing between them.
• Separate tenants for different customer populations, especially when data sensitivity differs.

Examples that auditors often treat as weak because they don’t enforce privilege constraints by themselves:

• Naming conventions, resource tags, folders, or dashboards without IAM enforcement.
• A single shared admin role that works everywhere, with “policy says don’t use it.” Policies help; they do not create a separate domain.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data that adopt NIST SP 800-53 Rev. 5 as the control baseline. ²

Operational scope (where it shows up in real programs)

• Centralized platforms where a single identity plane controls many environments (cloud control planes, CI/CD, EDR, IAM, data platforms).
• Multi-tenant SaaS where internal operators support multiple customers.
• Organizations with third-party administrators, managed service providers, or outsourced DevOps/SOC functions who need access that should be limited to specific environments or customer tenants.

What you actually need to do (step-by-step)

1) Define domains with a rule an engineer can implement

Create a short “Processing Domain Standard” (one page is fine) that answers:

• What counts as a domain in your environment (account/subscription, tenant, cluster, segment).
• The minimum required domain separations (example: production must be a separate domain from non-production).
• The allowed paths between domains (example: CI can deploy to prod, but developers cannot directly administer prod).
• The approval authority for creating a new domain or collapsing domains.

Keep it crisp; auditors want clarity and consistency, not a novel.

2) Build and maintain an inventory of domains

You need an authoritative list of domains and what they contain. Minimum fields:

• Domain name and type (prod, non-prod, customer tenant, regulated enclave).
• Systems/data classes in the domain.
• Domain owner (engineering) and control owner (security/GRC).
• Identity boundary (which IdP/tenant/account governs access).
• Network boundary summary (segmentation approach).

This inventory becomes your evidence backbone for AC-6(4).

3) Map roles to domains (RBAC/ABAC scoping)

Create an access matrix that is domain-aware. For each role (human and service accounts):

• Allowed domains (explicit list).
• Allowed privileges within each domain.
• Prohibited cross-domain privileges (example: “Support Engineer can access customer tenant A only when assigned; no global tenant admin”).

If you already run a JML process (joiner/mover/leaver), add “domain assignment” as a required attribute.

4) Enforce domain boundaries with technical controls

Pick enforcement mechanisms that are hard to bypass:

Identity boundary controls

• Separate cloud accounts/subscriptions with IAM scoped to the account.
• Separate admin roles per domain (no “global admin everywhere” except tightly controlled break-glass).
• Conditional access and MFA for privileged access per domain, if available in your stack.

Network boundary controls

• Segmentation that blocks default lateral movement between domains.
• Allow-listed interconnects where a business flow requires it (example: centralized logging ingestion).

Platform boundary controls

• Separate clusters/control planes for materially different privilege models.
• Separate CI/CD deployment credentials per domain; pipelines should not share a single omnipotent credential.

Your assessor does not need perfection, but they need to see real separation that enables finer-grained privilege allocation. ¹

5) Put guardrails around “global” and “break-glass” access

Global access is where AC-6(4) tends to fail in practice. If you must have it:

• Limit to a small, named group.
• Require ticket-based approval for use (or a comparable workflow).
• Log every session and action and review those logs.
• Time-bound access where your tooling supports it.

Write down the exceptions and keep them auditable.

6) Prove it operates: reviews, testing, and drift control

Add operating routines that generate evidence:

• Periodic review of domain inventory changes (new accounts, new tenants, new clusters).
• Periodic review of privileged cross-domain roles and assignments.
• Config monitoring to detect accidental collapse of boundaries (example: new routes, overly broad IAM policies).

Most AC-6(4) findings are evidence failures: the separation exists, but nobody can demonstrate it consistently.

Required evidence and artifacts to retain

Keep evidence in a form an assessor can re-perform:

Design artifacts

• Processing Domain Standard (definition, required separations, exceptions).
• Domain inventory (current and versioned).
• Access model: RBAC/ABAC definitions showing role-to-domain mapping.

Implementation evidence (screenshots/exports/configs)

• Cloud org/account structure showing separate accounts/subscriptions.
• IAM policy samples demonstrating domain-scoped permissions.
• Network segmentation evidence (diagrams plus selected config snippets).
• CI/CD configuration showing distinct deployment credentials per domain.

Operational evidence

• Access reviews focused on privileged and cross-domain access.
• Break-glass access log extracts and approvals.
• Change records for creation/retirement of domains.

A practical tip: store “evidence packets” per domain (or per environment tier) so audits do not turn into a scavenger hunt.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Define processing domain in your environment. What are the domains?”
• “Show me that production is a separate domain. Where is it enforced?”
• “Who has admin across multiple domains? Why, and how is it controlled?”
• “How do third parties access only the domains they support?”
• “What prevents a developer credential from being used in production?”
• “How do you detect drift that weakens segmentation or IAM scoping?”

Hangup to watch: teams show diagrams but cannot produce IAM evidence that privileges are actually domain-limited.

Frequent implementation mistakes (and how to avoid them)

1. Calling tags/folders a domain.
   Fix: require an enforcement mechanism (IAM boundary, tenant boundary, account boundary, or network segmentation) in your definition.

2. One “platform admin” group with access everywhere.
   Fix: split admin roles per domain, keep a small break-glass path, and evidence its oversight.

3. Shared CI/CD credentials across environments.
   Fix: separate deployment identities per domain and restrict their scopes.

4. Domains exist, but no inventory and no owner.
   Fix: domain inventory with ownership, reviewed as part of change management.

5. Third-party access is “all or nothing.”
   Fix: contract and implement domain-scoped access, with temporary elevation when needed.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite any enforcement actions.

Risk-wise, AC-6(4) reduces two common failure modes:

• Privilege sprawl: users accumulate rights across unrelated systems because the boundary is missing.
• Blast radius: compromise of a privileged identity affects multiple environments or customer populations.

For regulated or federal-aligned environments, assessors typically treat weak separation as a design flaw in least privilege, not a minor documentation issue. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and definitions)

• Name the control owner and the engineering owner for domain architecture.
• Publish a Processing Domain Standard with your minimum separations and exception process.
• Create the initial domain inventory from cloud org charts, network diagrams, and platform inventories.
• Identify your top cross-domain privilege risks (global admin, shared CI/CD secrets, shared prod/non-prod credentials).

By 60 days (enforce the highest-value boundaries)

• Implement or tighten separation for production versus non-production using an enforceable boundary (account/subscription or equivalent).
• Split privileged roles by domain; document and constrain break-glass access.
• Update JML workflows so domain assignment is explicit and reviewed.
• Start generating recurring evidence: privileged access review records and break-glass logs.

By 90 days (operationalize and make it audit-ready)

• Extend domain separation to other meaningful boundaries (customer tenants, regulated data enclaves, corporate IT versus product systems).
• Add drift detection for IAM and segmentation changes that weaken domains.
• Run a tabletop audit: pick one role and prove, end-to-end, that it cannot administer outside its assigned domain without exception workflow evidence.
• Consider tracking AC-6(4) in a system like Daydream so domain inventory, control ownership, procedures, and recurring evidence live together and stay assessment-ready. ¹

Frequently Asked Questions

What counts as a “processing domain” for AC-6(4)?

A processing domain is any boundary that actually constrains privileges in practice, such as a separate cloud account/subscription, tenant, or segmented environment with enforced IAM and network controls. If crossing the boundary does not require different access grants, it’s usually not a real domain for AC-6(4). ¹

Do we have to create more environments to meet the requirement?

Not necessarily. You need enough separation to allocate privileges more precisely; many programs start with production versus non-production and expand only where risk or data sensitivity demands it. ²

How should we handle engineers who need occasional production access?

Use domain-scoped roles by default, and a controlled elevation path for production (approval, time-bounding where feasible, and logging with review). Keep the exception process documented and evidenced. ²

We’re a SaaS provider. Does “separate processing domains” mean separate infrastructure per customer?

AC-6(4) does not mandate a specific architecture in the provided text. You must be able to allocate privileges at a finer grain, so many SaaS teams implement tenant-level isolation in the control plane and strictly scope support access per tenant. ¹

What evidence do auditors ask for most often?

They ask for a domain inventory, examples of domain-scoped IAM policies/roles, proof that production is isolated, and records showing privileged cross-domain access is controlled and reviewed. Make sure your evidence is reproducible, not just a diagram. ²

How does AC-6(4) relate to least privilege in AC-6?

AC-6 sets the least privilege expectation; AC-6(4) adds a design mechanism to make least privilege practical by creating domains that allow access to be scoped and constrained. It’s a structural control that supports day-to-day access decisions. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5