Building Your Style Workflow: A Yarrow Guide to Process Comparisons

Every access control system promises security, but the real test is how it fits into your team's daily workflow. When we compare processes—not just features—we start asking the right questions: Who requests access? Who approves? How is policy enforced? How do exceptions get handled? This guide builds a reusable comparison framework, using access control as our domain, so you can evaluate any workflow with clarity.

Why Process Comparisons Matter for Access Control

Access control decisions ripple through an organization. A poorly chosen workflow can mean hours of manual approvals, stalled projects, or security gaps that go unnoticed until an audit. Yet many teams pick a model based on what's familiar or what a vendor pitches, without stepping back to compare the underlying process.

The stakes are higher than ever. As organizations adopt cloud infrastructure, microservices, and zero-trust architectures, the number of access decisions per second explodes. A process that worked for a 50-person office with on-premise servers can become a bottleneck—or a sieve—when scaled to hundreds of employees and thousands of automated service accounts.

We've seen teams default to role-based access control (RBAC) because it's the industry standard, only to discover that their roles multiply into dozens of near-identical variants, creating maintenance nightmares. Others jump to attribute-based access control (ABAC) for its flexibility, but underestimate the effort of defining and governing attributes consistently across systems.

The core insight is this: every access control model encodes a workflow—a sequence of steps from request to enforcement. By comparing these workflows at a conceptual level, you can predict which models will align with your organization's culture, compliance needs, and operational capacity. This isn't about ranking models; it's about building a decision framework that you can apply to any new approach.

This guide is for engineers, security architects, and technical leads who need to choose or advocate for an access control workflow. We'll avoid vendor buzzwords and focus on the process mechanics that determine success or failure. By the end, you'll have a structured way to compare any access control approach—whether it's DAC, MAC, RBAC, ABAC, or policy-as-code—and know which fits your context.

What We Mean by 'Workflow' in Access Control

Workflow here refers to the sequence of steps involved in granting, enforcing, and revoking access. It includes the actors (requester, approver, administrator, system), the triggers (request, policy change, time-based event), and the feedback loops (audit logs, recertification). Comparing workflows means looking at how these elements interact, not just at the final access matrix.

Core Idea: Comparing Access Control Workflows by Process Archetypes

At the heart of our approach is the idea that access control models can be grouped into a few process archetypes. Each archetype has a distinct pattern for how access decisions are made, how policies are defined, and how enforcement happens. By recognizing these archetypes, you can quickly map a model to your organization's needs.

The three primary archetypes we'll use are:

• Predefined Policy Models (e.g., MAC, DAC): Access is determined by fixed rules or ownership. The workflow is rigid, with little room for context. Best for environments with stable requirements and high security needs, like classified systems.
• Role-Based Models (e.g., RBAC): Access is tied to organizational roles. Workflow centers on role definition, user assignment, and periodic review. Balances flexibility and control, but can suffer from role explosion.
• Attribute-Based Models (e.g., ABAC, policy-as-code): Access decisions consider multiple attributes (user, resource, environment). Workflow emphasizes policy authoring, attribute governance, and real-time evaluation. Highly flexible, but requires strong data discipline.

These archetypes are not mutually exclusive. Many organizations build hybrid workflows—for example, using RBAC for base permissions and ABAC for fine-grained conditions. The key is to understand the workflow implications of each archetype: who is involved in policy changes, how long it takes to grant access, and how easy it is to audit.

Let's make this concrete. Consider a typical employee onboarding workflow. In a pure RBAC system, the workflow might be: HR assigns a role (e.g., 'Developer'), which automatically grants a predefined set of permissions. The process is fast and consistent, but if the role is too broad, the employee gets more access than needed. In an ABAC system, the workflow could be: HR provides attributes (department, project, clearance level), and a policy engine evaluates access at runtime based on those attributes plus context (time of day, location). This is more granular, but the policy authoring and attribute maintenance require ongoing effort.

The comparison framework we propose uses four dimensions: Policy Definition (how rules are created and updated), Decision Point (where access decisions are made), Enforcement Scope (how broadly the policy applies), and Audit Trail (how easily you can trace who had what access and why). Each archetype scores differently on these dimensions, and your organization's priorities will determine which trade-offs are acceptable.

Why Process Archetypes Beat Feature Checklists

Feature checklists (supports X protocol, integrates with Y) are useful for shortlisting, but they don't reveal how a system will behave under pressure. Process archetypes force you to think about the day-to-day experience: How long does a policy change take? Who can approve an emergency access? What happens when an attribute source goes down? These are the questions that determine whether a workflow is sustainable.

How It Works Under the Hood: The Mechanics of Each Archetype

To compare workflows effectively, we need to understand the internal mechanics. Let's examine each archetype's core loop: the sequence of events from a user's access request to the decision.

Predefined Policy Models (MAC/DAC)

In Mandatory Access Control (MAC), the system enforces policies based on labels (e.g., security clearance). The workflow is: User requests access to an object → System compares user's label to object's label → Grant or deny. The decision is made without human intervention. Discretionary Access Control (DAC) shifts control to the object owner, who can grant permissions at their discretion. The workflow is: Owner sets permissions on an object → User requests access → Owner or system checks permissions. Both models are simple and deterministic, but they lack flexibility. In MAC, changes require reclassification, which is slow. In DAC, permissions can become inconsistent as owners change.

Role-Based Access Control (RBAC)

RBAC introduces roles as an abstraction layer. The workflow has three stages: (1) Role engineering—defining roles based on job functions. (2) User assignment—mapping users to roles. (3) Permission assignment—mapping roles to permissions. When a user requests access, the system checks if their role includes the required permission. The decision is static; it doesn't consider context. The strength of RBAC is its manageability: adding a new user means assigning a role, not setting dozens of individual permissions. The weakness is role explosion: as the organization grows, roles proliferate to cover edge cases, leading to a maintenance burden. Periodic recertification becomes critical to prune stale roles.

Attribute-Based Access Control (ABAC) and Policy-as-Code

ABAC evaluates access based on attributes of the user, resource, action, and environment. The workflow is: User requests access → Policy engine collects attributes from multiple sources (HR database, asset registry, time service) → Evaluates a policy (e.g., 'Allow if user.department equals resource.department AND time is within business hours') → Grant or deny. The decision is dynamic and context-aware. Policy-as-code takes this further by treating policies as version-controlled code, enabling CI/CD pipelines for policy changes. The workflow for policy-as-code includes: Author policy in a declarative language (e.g., Rego, Cedar) → Test in a sandbox → Deploy via pipeline → Monitor for violations. This archetype offers maximum flexibility but requires investment in attribute governance and policy testing. A common pitfall is attribute sprawl: when attributes are defined inconsistently across systems, policies become unreliable.

Comparing the Decision Loop

All three archetypes share a basic decision loop: Request → Collect context → Evaluate policy → Enforce decision → Log. The differences lie in how 'context' is defined and how 'policy' is authored. In MAC, context is a single label; in RBAC, it's a role; in ABAC, it's a set of attributes. The more context you include, the more granular your control, but the more complex your workflow becomes. The trade-off is between simplicity and expressiveness.

Worked Example: A Growing SaaS Company Chooses a Workflow

Let's walk through a composite scenario. A SaaS company with 200 employees is scaling rapidly. They currently use a simple DAC model: each team lead manages permissions for their team's resources. As the company grows, this creates problems: permissions are inconsistent, onboarding takes days, and audit reports are a mess. The security team wants to move to a more structured workflow.

They evaluate three options: RBAC, ABAC, and a hybrid RBAC-ABAC approach. Using our process archetype framework, they map out the workflow implications.

Option 1: Pure RBAC — They define roles like 'Engineer', 'Sales', 'Admin'. Each role gets a set of permissions. Onboarding becomes: HR assigns role → system grants permissions. The workflow is fast and easy to audit. But after a year, they have 40 roles, many differing by only one permission. Role explosion sets in. The team spends hours in recertification meetings, debating whether 'Senior Engineer' needs access to the billing system. The trade-off: simplicity at scale becomes complexity.

Option 2: Pure ABAC — They define policies like 'Allow access to project resources if user's department matches project department and user's role is at least Contributor'. The workflow is flexible: a new project can be set up without creating a new role. But they quickly discover that attributes are messy: the HR system has 'department' as a free-text field, so 'Engineering' and 'engineering' are treated differently. The policy engine returns inconsistent results. They spend months cleaning up attribute data. The trade-off: flexibility requires data discipline.

Option 3: Hybrid RBAC-ABAC — They use RBAC for coarse-grained access (e.g., 'Engineer' role grants access to code repositories) and ABAC for fine-grained conditions (e.g., 'only during business hours' or 'only for projects the user is assigned to'). The workflow is: assign role for base permissions, then layer attributes for context. This balances manageability and flexibility. The onboarding time is moderate: HR assigns a role, and project leads set additional attributes. The audit is straightforward for base permissions, but more complex for attribute-based decisions. The team decides this hybrid model fits their growth trajectory best.

This scenario illustrates that no single archetype is universally best. The right choice depends on your organization's tolerance for complexity, data quality, and the speed at which you need to adapt.

Key Takeaways from the Scenario

The company's decision hinged on two factors: the maturity of their attribute data and the expected rate of role proliferation. They also considered the operational cost of policy changes. Each option had a different 'change workflow': in RBAC, changing a permission meant editing a role; in ABAC, it meant editing a policy; in the hybrid, it could be either. The hybrid gave them the option to choose the simplest path for each change.

Edge Cases and Exceptions

Every access control workflow has edge cases where the standard process breaks down. Identifying these in advance helps you choose a model that can handle your worst-case scenarios.

Emergency Break-Glass Access

In critical situations, a user may need immediate access to a system that their normal permissions deny. A break-glass workflow allows overriding policies, but it must be tightly controlled. In RBAC, break-glass often means adding a temporary role with full access, which is simple but hard to audit. In ABAC, break-glass can be implemented as a policy that activates under specific conditions (e.g., 'if incident ticket is open and time is after hours'). The workflow must include automatic notification and post-incident review. Not all models handle this gracefully; MAC systems typically don't allow break-glass at all.

Cross-Domain Delegation

When users need access to resources managed by a different team or organization, the workflow becomes complex. In RBAC, cross-domain access often requires creating a federated role or using claims. In ABAC, it's easier: you can define a policy that trusts attributes from an external identity provider. But the workflow must include attribute mapping and trust agreements. A common failure is assuming that attribute names mean the same thing across domains. The process should include a validation step.

Transient and Ephemeral Access

In DevOps environments, service accounts may need access for only a few minutes to deploy a change. Traditional workflows that require a human approval each time are too slow. Policy-as-code excels here: you can define a policy that grants access based on a CI/CD pipeline token with a short expiry. The workflow is fully automated. But if the pipeline is compromised, the blast radius is large. The trade-off is between speed and security, and the workflow must include robust logging and anomaly detection.

Regulatory Compliance Constraints

Regulations like HIPAA or PCI-DSS impose specific requirements on access control workflows. For example, they may require that access decisions be logged with a reason, or that privileged access be approved by a separate team. Some archetypes make this easier. RBAC with a well-defined approval workflow can satisfy many compliance needs. ABAC, if not carefully designed, can make it harder to prove that access was appropriate because the decision factors are more complex. The workflow should include a compliance review step before deployment.

Limits of the Approach

Our process comparison framework is a powerful mental model, but it has boundaries. First, it focuses on workflow at a conceptual level, not on implementation details. Two systems that implement the same archetype can have vastly different performance, scalability, or integration capabilities. The framework helps you choose the right archetype, but you still need to evaluate specific products or open-source tools for operational fit.

Second, the framework assumes a certain level of organizational maturity. For a small startup with five employees, a formal process comparison may be overkill. A simple DAC model might be sufficient. The framework is most useful when you have at least 50 employees and growing, or when compliance requirements force a structured approach.

Third, the archetypes are simplifications. Real-world implementations often blend elements. For example, many RBAC systems support attribute-based conditions (sometimes called 'dynamic RBAC'). Our framework can still guide you: identify which archetype is dominant and use that as your anchor for comparison. But be aware that the lines are blurry.

Fourth, the framework does not account for organizational culture. A workflow that requires frequent policy reviews may fail if your team is averse to meetings. A workflow that relies on self-service attribute updates may fail if users don't keep their attributes current. The framework should be complemented by a cultural assessment: talk to your team about their workflow preferences and pain points.

Finally, the framework is not a one-time exercise. As your organization evolves, the optimal workflow may change. A model that fits today may become a bottleneck next year. We recommend revisiting your workflow comparison annually, or whenever a major change occurs (e.g., acquisition, new product line, regulatory shift).

When to Use a Different Framework

If your primary concern is vendor selection, supplement this framework with a feature matrix and proof-of-concept testing. If you're focused on compliance, map each workflow to specific regulatory requirements. If you're dealing with legacy systems, consider the migration path: can you layer a new workflow on top, or do you need to replace the system entirely? Our framework is a starting point, not a substitute for due diligence.

To move forward, start by mapping your current access control workflow using the four dimensions: Policy Definition, Decision Point, Enforcement Scope, and Audit Trail. Identify pain points and bottlenecks. Then, use the archetypes to brainstorm alternatives. Finally, prototype the most promising workflows with a small team before rolling out broadly. The goal is not perfection, but continuous improvement—a workflow that evolves with your organization's needs.