Purpose and scope
Most enterprises can list their security controls. Fewer can show how those controls behave where one domain hands off to another. A cloud team owns the platform, an identity team owns access, an application team owns the code and a data team owns the stores. Each domain can be well run while the path between them stays open.
This guide gives architects and security leaders a control map organized by where a control is enforced, plus a method for finding the boundaries where enforcement is missing or only assumed. It supports architecture decisions. It does not select products, and it is not a compliance mapping.
The map sits above the detailed catalogs. For control-level specification, NIST SP 800-53 and the CIS Critical Security Controls remain the usual references.
Design principles
-
Start from outcomes, not products. A control exists to guarantee something. Write that guarantee first.
-
Give every control an owner, an enforcement point and evidence. A control missing any of the three is an intention.
-
Treat identity as the common dependency. Almost every other domain relies on a decision made by an identity system.
-
Assume a boundary will eventually be crossed. Design the next layer to limit what follows.
-
Report control state honestly. Use four states: enforced, monitored only, assumed, and absent.
The control map
The eight domains below cover where enterprise security controls operate. They align with the six functions of the NIST Cybersecurity Framework 2.0 (govern, identify, protect, detect, respond and recover) and with the five pillars and three cross-cutting capabilities of the CISA Zero Trust Maturity Model, but they are arranged by enforcement location, because that is where architecture decisions are made.
| Domain | Security outcome | Core controls | Evidence it works |
|---|---|---|---|
| 1. Governance and risk context | Control investment follows business risk | Risk appetite; control ownership; exception handling with expiry; inventory of critical services, data and assets | Controls traced to critical services; exceptions with an owner and an end date |
| 2. Identity, human and machine | Only the right principal gets the right access for the right time | Strong authentication; privileged access management; joiner, mover and leaver processes; workload and service identity; secrets management; federation controls | Share of privileged and machine identities under management; time to revoke; tested resistance of the MFA methods in use |
| 3. Endpoint and device | The device presenting a credential can be trusted | Hardening; endpoint detection and response; device posture used in access decisions; patching | Posture signals change access decisions, not just reports |
| 4. Network and connectivity | Reach and lateral movement are limited | Segmentation; identity-aware access to applications; egress control; traffic and DNS inspection | Tested paths are blocked; unexpected east-west flows raise alerts |
| 5. Cloud and platform | The management plane and configurations stay in a known, safe state | Landing zones; policy as code; posture management; control plane logging; workload protection; SaaS configuration baselines | Drift detected and corrected within a defined time; control plane activity monitored |
| 6. Application and API | Software does only what its design allows | Threat modeling; secure build pipeline; dependency and build integrity; API authentication and object-level authorization | Findings closed by severity; complete API inventory; verifiable build provenance |
| 7. Data | Protection follows the data, not its location | Classification; access control; encryption and key management; data loss prevention; backup integrity | Inventory of data stores; key access reviewed; restores tested |
| 8. Detection, response and recovery | Attacks are noticed, contained and recovered from | Telemetry; detection engineering; response playbooks; immutable backups; recovery sequencing | Detections tested against attack steps; exercises run; recovery time demonstrated |
Three capabilities run across all eight domains: visibility and analytics, automation and orchestration, and governance. They are not separate layers. A domain without telemetry cannot be monitored, a domain without automation cannot keep pace with change, and a domain without governance drifts.
Where controls fail: the boundaries
The failure descriptions below are patterns, not statistics. Two are drawn from published incident analyses: Microsoft’s account of an actor using a compromised test account and malicious OAuth applications to reach corporate mail, and Google Threat Intelligence Group’s account of stolen OAuth tokens for a third-party sales application being used to export data from customers’ Salesforce instances. The rest follow from how the domains interact.
| Boundary | Typical failure | Design response | Test that proves it |
|---|---|---|---|
| Identity and cloud | Roles and workload identities accumulate permissions; a federation trust into the cloud management plane is broader than intended; a stolen token acts as an administrator | Least-privilege role design with short-lived credentials; separate administrative identities; monitoring of federation and role changes | Attempt a path from a standard identity to cloud administrator and confirm detection fires |
| Identity and SaaS | Integrations hold standing OAuth access that sits outside the user’s own MFA and conditional access, so one stolen token reaches data at scale | Restrict user consent; inventory integrations and their scopes; shorten token lifetimes; review third-party permissions on a schedule | Revoke one integration’s tokens and record what breaks and what alerts |
| Application and data | A service account reads an entire datastore; an API returns more objects than the caller should see | A distinct identity per service; scoped data access; object-level authorization checked at the data or API layer | Call the API as a low-privilege user against another user’s objects |
| Network and identity | Segmentation is defined by address ranges while access is granted by identity; a flat network sits behind a remote access gateway | Identity-aware access to applications; segmentation by workload and sensitivity; no trust granted by network location alone | Compromise a standard endpoint in a test and measure what it can reach |
| Cloud and on-premises | Directory synchronization and shared administrative accounts let a compromise in one estate reach the other | Separate privileged identities per estate; treat synchronization and federation components as the most sensitive assets | Map which on-premises compromises yield cloud administration, and the reverse |
| Control and detection | Controls enforce but emit no usable telemetry; logs exist but nobody tests whether detections fire | Make logging a requirement of every control definition; build detection use cases per boundary | Replay attack steps and verify the alert, the owner and the time taken |
Decisions that shape the map
Five decisions shape most versions of this map. Each has a trade-off that depends on the organization, so the guidance here is a starting position, not a rule.
| Decision | Options | Trade-off | Starting position |
|---|---|---|---|
| Where to enforce access decisions | Network edge; identity provider; application or data layer | The edge is simple and coarse. The identity provider is flexible but concentrates dependency. The application layer is most precise and costly to retrofit. | Enforce coarse policy centrally and sensitive access at the application or data layer. Make policy decision and enforcement points explicit, as NIST SP 800-207 describes. |
| Native or overlay controls | Platform-native controls; third-party overlay | Native controls integrate tightly but vary by platform. Overlays give consistency and add a dependency. | Use native controls for the baseline. Add an overlay only where consistency across platforms is the requirement. |
| Who owns operation | Central security team; platform teams within guardrails | Central ownership gives consistency and becomes a bottleneck. Federated ownership gives speed and drifts. | Set standards centrally, operate in the platform teams, verify centrally. |
| Prevent or detect | Invest in blocking; invest in detection and response | Prevention cannot cover every path. Detection costs analyst time and arrives after the action. | Prevent where an action is irreversible. Detect where it is reversible and the path is too broad to close. |
| What counts as tier zero | Narrow definition; broad definition | A narrow definition is manageable and misses systems that can reach the crown jewels. A broad one dilutes protection. | Include anything that can administer identity, the cloud management plane, backups or security tooling, and protect it separately. |
Using the map
-
Choose one business service or crown jewel. List the identities, applications, data stores and infrastructure it depends on.
-
Record the control state in each domain as enforced, monitored only, assumed or absent. Enforced means a technical mechanism prevents the action. Assumed means a policy or process exists and nothing checks it.
-
Trace one realistic attack path across the boundaries, for example a phished user, then a SaaS integration, then a data store. Mark every step where the state is assumed or absent.
-
Prioritize by impact on the service and by path length, not by a score per domain.
-
Test every claim of enforcement with the tests in the boundary table, and record the result.
-
Review the map when the architecture changes materially: a new cloud platform, an acquisition, or the introduction of AI agents with tool access.
ASSUMED IS THE STATE TO WATCH A control that is assumed has a policy, an owner and a place in the audit file. Nothing checks it. Most of the exposure in an architecture review sits in this category. |
Common mistakes
-
Mapping products to boxes. The map describes guarantees. A product inventory does not show whether the guarantee holds.
-
Averaging maturity across domains. The average hides the weakest boundary, and the attacker will use that one.
-
Treating framework mapping as coverage. Showing that a control satisfies a framework requirement does not show that it works against the paths above.
-
Leaving boundaries without an owner. If two teams each assume the other covers the handoff, nobody does.
-
Under-protecting tier zero. The systems that administer everything often have weaker controls than the systems they administer.
Use this map to inform security architecture decisions. A workable first step is to run it for one business-critical service and count the boundaries marked assumed. Teams that want an independent review of that exercise can start a conversation with Cybrilliant’s security architecture specialists.
Related Reading
Zero Trust Beyond the Network Diagram
Article on applying zero trust principles to decisions that reach past network design.
Identity-Aware Network Segmentation
Article on segmenting by identity and workload instead of address range.
SaaS Security: The Control Gaps Between Tenant and Enterprise
Article on where SaaS platform controls end and enterprise responsibility begins.
Security Engineering: Turning Control Requirements Into Working Systems
Field Note: Paved Roads, Not Gatekeeping: Security Engineering That Scales
Replacing review queues with templates and pipeline checks that scale.
Sources
-
NIST. The NIST Cybersecurity Framework (CSF) 2.0. nist.gov/cyberframework
-
NIST. Special Publication 800-207, Zero Trust Architecture. csrc.nist.gov
-
NIST. Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations. csrc.nist.gov
-
CISA. Zero Trust Maturity Model. cisa.gov/zero-trust-maturity-model
-
Center for Internet Security. CIS Critical Security Controls. cisecurity.org
-
Microsoft Security Blog. Midnight Blizzard: Guidance for responders on nation-state attack. microsoft.com/security/blog
-
Google Threat Intelligence Group. Report on the Salesloft Drift OAuth token compromise (UNC6395). cloud.google.com/blog/topics/threat-intelligence
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionProtect What MattersGuard the identities, data and systems the business depends on.See how we work →Related service
Security Architecture
Use this to inform security architecture decisions.