Appendix B — Business Authorization and Least Privilege in the Hybrid Architecture

 1. Business Authorization: A Challenging Requirement for GovCon

GovCon organizations operating under CMMC Level 2, NIST SP 800-171, DFARS 252.204-7012, and Zero Trust (NIST SP 800-207) are required to manage business authorization, least privilege, need-to-know, and separation of duties across operational actions and document access. These requirements apply not only to privileged system functions and documents (CUI), but to the full range of GovCon operations—BD, Capture, Proposal Management, Contracts, Subcontracts, Program Management, Finance, and Compliance.

GovCon documents are business artifacts linked to contracts, programs, pursuits, workflow steps, and approvals. Entitlement to view or act on them requires business authorization. This is typically managed by your business systems operating in an “execution plane”. They natively provide business context and role-based controls to demonstrate business authorization. GovCon organizations have found that using Microsoft 365 it is practically not possible to meet business authorization requirements.

This appendix explains the regulatory basis for business authorization, the realities of how and where to manage it, and how the R3 Hybrid model handles it.

 

2. Regulatory and Standards Basis for Business Authorization

NIST SP 800-171 (CMMC Level 2)

The core access control requirements mandate authorization grounded in business roles and responsibilities:

• AC-3 Access Enforcement — Enforcement must be based on role and contextual rules.
• AC-5 Separation of Duties — Sensitive responsibilities must be distributed across roles.
• AC-6 Least Privilege — Users must have only the information and functions required for their duties.

These controls govern operational access and information access—not storage location.

 

Zero Trust Architecture (NIST SP 800-207)

Zero Trust distinguishes between:

• control-plane operations (business actions, workflows, roles), and
• data-plane access (file-level access).

Authorization must incorporate identity, posture, and business context, which only execution systems maintain.

 

DFARS 252.204-7012

DFARS defines where CUI must be stored (e.g., GCC High).
Operational entitlement remains governed by NIST AC-family controls.

Together, these frameworks require business-context-driven authorization, which can only be enforced in the Execution Plane.

 

3. Why Business Authorization Belongs in the Execution Plane

3.1 Execution Plane Holds the Business Context (with R3 RBAC)

The Execution Plane maintains the business relationships that determine entitlement:

• contract, program, pursuit, and subcontract ownership
• workflow stages and approval paths
• team membership and role assignments
• business-unit alignment
• delegated authority and segregation-of-duties rules

These elements determine who should access a document and who is authorized to perform specific operational actions.

 

R3 RBAC and Business Authorization

R3’s Role-Based Access Control enforces these rules by:

• Binding user roles directly to GovCon business records
• Dynamically determining visibility and permissible actions based on workflow state and assignment
• Enforcing segregation-of-duties and delegated authority
• Governing entitlement at the record, role, and action level

This is how least privilege, need-to-know, and operational authorization are implemented in the Execution Plane.

 

Industry Norm: Business Systems Perform Business Authorization

In all mature enterprise domains—ERP, CRM, CLM, HR, Finance—business authorization is implemented in the execution layer because operational decisions depend on business context, not file locations.

All GovCon organizations likewise operate within an Execution Plane, but many do so without a clean separation between their business systems and their document environment. Without a clear boundary between the Execution Plane and the Document Control Plane, business authorization is difficult to implement using the location-based controls in Microsoft 365. The Hybrid Model establishes this boundary, enabling business authorization in the Execution Plane and document security in Microsoft 365 as separate, complementary layers.

 

3.2 Document Security in the Document Control Plane (Microsoft 365)

Microsoft 365 provides secure storage and forms the CUI boundary, but it is not designed to implement business authorization.

Location-Based Security

Document and data security in Microsoft 365 is tied to where content lives, not to the business context that determines who should have access.

Microsoft 365 secures content using:

• site collections
• sites
• libraries
• folders
• files

These ACLs are tied to containers, not business meaning.

Lack of Business Context

Microsoft 365 does not understand:

• which contract, program, pursuit, or subcontract a document belongs to
• which users are assigned to that work
• workflow state
• delegated authority
• segregation-of-duties constraints

It cannot infer need-to-know.

 

Container Models Cannot Express Business Authorization

Attempts to replicate GovCon business context with container-based ACLs inevitably lead to:

• ACL sprawl
• over-permissioned areas
• inconsistent inheritance
• access mismatches when teams or workflows change

Microsoft 365 provides document-level security, not business authorization.

The Common GovCon Gap

Because of these limitations, most GovCon organizations end up with an informal policy:

“Anyone allowed to access GCC High is implicitly authorized to access all documents stored there including all CUI.”

This has historically passed many CMMC assessments because auditors focused on storage protections rather than operational least privilege. However, assessor behavior is changing. Auditors are increasingly evaluating whether operational access controls reflect actual need-to-know, not just document storage controls. This creates a growing risk for organizations relying solely on Microsoft 365 tenant boundary for entitlement.

 

3.3 Execution Plane Applies Authorization and Brokers Document Access

In the Hybrid Architecture:

1. Execution Plane (R3)
   • Determines entitlement using business context and RBAC
   • Enforces least privilege, need-to-know, workflow gating, and segregation-of-duties rules
   • Governs all document-access privileges and operational actions
2. Document Control Plane (Microsoft 365)
   • Stores and protects all documents (CUI and non-CUI)
   • Enforces storage container-level ACLs
   • Maintains the CUI boundary and platform protections
3. Access Brokering
   • Users access documents through the Execution Plane
   • R3 determines who should access
   • Microsoft 365 enforces how access is performed

 

3.4 Execution Plane as the Collaboration Plane

The Execution Plane is also where cross-functional collaboration occurs.
Routing collaboration through the Execution Plane ensures:

• need-to-know is preserved
• teams access only what they are responsible for
• workflow transitions do not leak visibility
• delegated authority is honored

This is both a productivity best practice and a compliance requirement.