# Map cloud access control to the service layer that actually makes the decision > IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it. - Canonical URL: https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:06+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it. ## Potentially affected Organizations using infrastructure, platform, or software cloud services, especially where provider, tenant, application, and data-layer authorization overlap. ## DSE recommendation Create an access-decision map across provider and customer layers, define owners and authoritative policy for each decision, and test effective access with representative identities rather than relying on role names alone. ## Article Bottom line: “cloud access” is rarely one control. A request may cross provider administration, tenant identity, platform policy, application roles, resource permissions, data filtering, network boundaries, and support channels. Map the layer that makes each decision before assigning or reviewing access. ## Source fact: what NIST covers [NIST SP 800-210](https://csrc.nist.gov/pubs/sp/800/210/final) presents cloud access-control characteristics and general guidance for infrastructure, platform, and software service models. NIST notes that the models expose different types of components and access. It describes them as hierarchical in the sense that guidance for lower-level functional components can remain relevant when those components appear within higher-level models, while each service model retains its own access-control focus. This supports an important operating distinction: the provider’s controls and the customer’s controls can both matter, but they do not necessarily make the same decision or produce the same evidence. ## What the source does not establish The publication does not certify a cloud service or prescribe exact product roles. It does not prove that a provider role, tenant group, application role, and data permission align. A least-privilege name is not evidence of least-privilege behavior. The source also does not establish contractual responsibility, licensing, feature availability, or log retention for a particular service. Those facts must come from current service documentation and the customer’s agreement and configuration. ## Applicability questions - Which service model and functional components are in scope for this resource? - At which layer is authentication performed, and at which layers is authorization re-evaluated? - Which provider, tenant, application, data, automation, and support identities can affect the resource? - Where is policy configured, who can change it, and which logs show the resulting decision? - Can an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission? ## DSE recommendation: create an access-decision map The following steps are DSE recommendations based on the cited source. - For each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source. - Separate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts. - Inventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture. - Test effective access with representative accounts at each role and boundary. Include denied operations, cross-tenant or cross-project paths, and direct API access where supported. - Protect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events. - Re-run the map after service architecture, identity integration, subscription, or application behavior changes. ## Verification and evidence Retain the architecture and decision map, official responsibility documentation, exported role and policy configuration, effective-access tests, denied-event logs, privileged-change records, exception register, and review sign-off. Evidence should identify the tenant, subscription or project, region where relevant, resource, and test identity. ## Official references - [NIST SP 800-210 — General Access Control Guidance for Cloud Systems](https://csrc.nist.gov/pubs/sp/800/210/final) — National Institute of Standards and Technology; finalized July 31, 2020 ## Primary reference - Name: NIST SP 800-210 — General Access Control Guidance for Cloud Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/210/final - Source publication date: 2020-07-31 ## Citation and use Preferred citation: “Map cloud access control to the service layer that actually makes the decision,” DSE Security, https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.