Business Process and Policy Management Software: What It Governs, and What the Context Layer Has to Govern Instead

Emily Winks

Data Governance Expert

Updated:08/18/2026

Published:08/18/2026

19 min read

Watch Context Layer Live Get the AI Context Stack

Key takeaways

The phrase names two software markets, not one, and a search for it returns both without reconciling them.
Business process management software governs the work its engine orchestrates, on OMG notation last revised in 2014.
Policy management software governs the people who read a written rule, and its defining capability is attestation.
Both can be fully compliant and still govern nothing an agent does, because both address a human reader by design.

What is business process and policy management software?

Business process and policy management software names two distinct markets that one search collapses into one. Business process management software models, runs and monitors the processes an organization executes, and it governs the work its engine orchestrates, on public OMG notation: BPMN 2.0.2, DMN 1.5 and CMMN 1.1. Policy management software authors, versions, distributes and attests written policy, and it governs the people who read and acknowledge it. Both were addressed to a human reader on purpose, so the reach of both stops short of the moment an AI agent runs a query against a governed table.

What separates the two:

What each one governs. Orchestrated work on one side, the people who read a rule on the other
The artifact it produces. An executable process model, or a versioned written document
Where its reach ends. Outside the modeled process, or at the acknowledgment
What neither one reaches. A rule attached to the data and evaluated when the query runs

Can your agents see your rules?

Assess Context Maturity

Business process and policy management software names two markets, not one. Business process management software governs the work its engine orchestrates, on a notation (BPMN 2.0.2) last formally revised in January 2014; policy management software governs the person who reads and acknowledges a written rule. Atlan treats policy differently: as context attached to the data, evaluated when a query runs.

The two get typed as one search because they are sold as the same thing: both are marketed as data governance software, both produce an artifact stating what should happen, and both come out of the same risk budget. What separates them is reach. A workflow engine can only govern work it orchestrates; a written policy can only govern someone who reads it. This page answers the phrase as typed, defines each half by where its reach ends, then names the artifact neither half holds.

Business process management software governs the work an engine orchestrates: modeled processes, routing, approvals, running instances
Policy management software governs the people who read a rule: authoring, versioning, distribution, attestation
Both share one deliberate design decision: the addressee is a human being
An AI agent arrives at neither door. It arrives at the query, and a query is not a process instance or a signed page
The rule that has to hold for an agent lives in a third place: attached to the data, evaluated at request time

Fact	Detail
What the phrase covers	Two distinct software markets that one search collapses into one
What business process management software governs	The work its engine orchestrates: modeled processes, routing, running instances
What policy management software governs	The people who read a written rule and record that they read it
Who each addresses	Process stakeholders on one side; employees and reviewers on the other
Where each one’s reach ends	Outside the modeled process; at the acknowledgment
The standards underneath	BPMN 2.0.2, DMN 1.5, CMMN 1.1 (OMG); no public equivalent on the policy side
Analyst coverage in 2026	Business Orchestration and Automation Technologies; policy management sits inside GRC
What neither one reaches	The moment an AI agent runs a query against a governed table

Why does one search return two different kinds of software?

One phrase, two software markets. A search for it splits between them without reconciling them: run it yourself and roughly half of page one answers “what is policy management software,” the rest answers “what is business process management software,” and the related questions the search suggests split the phrase back into those halves. Nobody tells you that you asked about two things. (Business process management is also not business process outsourcing.)

Buyers shortlist inside each half, not across them. On the pure-play process side the names that come up are Appian, Bizagi, Camunda, Nintex, Pega and SAP Signavio. On the policy and GRC side: AuditBoard, ComplianceBridge, LogicGate, MetricStream, Mitratech, Navex, PowerDMS and Workiva.

Analyst coverage is asymmetric. Gartner retired the Magic Quadrant for Intelligent Business Process Management Suites, replacing it with the Magic Quadrant for Business Orchestration and Automation Technologies (Gartner, 2025), published 15 October 2025, which is explicitly about convergence of low-code platforms, robotic process automation, business process automation and integration, plus agentic features. There is no Magic Quadrant for policy management at all; it is covered as a capability inside governance, risk and compliance research.

Dimension	Business process management software	Policy management software
What it governs	The work its engine orchestrates	The people who read and acknowledge a rule
The artifact it produces	An executable process model	A versioned written document
Who it addresses	Stakeholders who design and run the work	Employees, reviewers, auditors
How a rule takes effect	The engine runs an instance and the step fires	A person reads the page and records it
Where its reach ends	Outside the modeled process	At the acknowledgment
The standard underneath	BPMN 2.0.2, DMN 1.5, CMMN 1.1 (OMG)	No public equivalent
The defining capability	Orchestration of modeled work	Attestation
Vendors buyers commonly evaluate	Appian, Bizagi, Camunda, Nintex, Pega, SAP Signavio	AuditBoard, ComplianceBridge, LogicGate, MetricStream, Mitratech, Navex, PowerDMS, Workiva
Analyst coverage in 2026	Business Orchestration and Automation Technologies	Inside GRC, no standalone market

These sit in our library as separate topics for the same reason: data policy setting tools and data policy enforcement tools are different jobs. Define each half by what it governs and where its reach stops, and the question becomes tractable, because the reach of both stops short of the same place.

What is business process management software, and what does it actually govern?

Business process management software models, runs and monitors the processes an organization executes, and it governs exactly the work it orchestrates. According to IBM, citing Gartner’s definition, business process management “employs methods to discover, model, analyze, measure, improve and optimize business strategy and processes.” The software is what makes that discipline executable.

Three public specifications sit underneath it, all from the Object Management Group. BPMN 2.0.2 (OMG, January 2014) is the process notation. DMN 1.5 (OMG, August 2024) is the decision model, a graphical notation plus an expression language for the rules a process consults. CMMN 1.1 (OMG, December 2016) covers case models, work that is real but not a fixed sequence. Almost no page on this topic links to any of the three, which is a shame, because they are the part that is actually specified.

Reach is the thing to hold onto. A rule encoded in a workflow governs the process instances the engine runs. Approve the refund above a threshold, hold the shipment until the check clears: genuinely governed and auditable, provided the work arrives as a step inside a modeled process. If it does not arrive that way, the engine never fires.

That is a design choice, and a good one. BPMN’s addressee is on the record in OMG’s own words: the notation is “intended to be used directly by the stakeholders who design, manage and realize business processes,” described as easy to use and flowchart-like. It is an excellent human-facing notation and was built to be one. The point is who it addresses, which is why a rule expressed this well can still sit outside the reach of computational governance and outside the reach of anything reading your data without a process wrapped around it.

What a context layer is, in plain language

Where policy, definitions and lineage have to live for an AI system to obey them at runtime, and what changes when they do.

Get the Context Layer Ebook

What is policy management software, and what does it actually govern?

Policy management software authors, versions, distributes and attests written policy, and it governs the people who read and acknowledge it. The artifact it produces is a versioned document, and the machinery around that document exists to move it to the right people and prove it arrived: drafting and approval, version control so you can show which text was in force on a given date, review cycles, distribution by role, and reporting.

Reach again. The policy takes effect through a person reading it and recording that they did. That record is the enforcement mechanism, and it is a good one: it survives an audit and establishes who knew what and when. Its reach ends at the acknowledgment, which is where it was designed to end. The stages either side of that moment are their own topic, covered in the data governance lifecycle and in AI-augmented governance policy lifecycle.

The category has no analyst market of its own either, checkable by absence: no Magic Quadrant for policy management, no standalone research treating it as a category. It appears as a capability inside governance, risk and compliance coverage. That is a fact about market structure, not a judgment about the tools.

Attestation is the defining capability, and attestation is a record that a person read a page. An AI agent’s execution path contains no such step. A tool built to prove a human read something is very good at proving a human read something; the written rule and its policy enforcement mechanism are simply addressed to the same reader as the process notation on the other side of this market.

Where do the two overlap, and what does neither one reach?

Neither category reaches the moment an AI agent runs a query. They overlap on the written rule and diverge on how it takes effect. Both hold the rule; both were built so a person could find it, read it and act on it. That shared design decision is the seam.

Take the workflow half. A workflow engine governs a process it orchestrates. An agent writing SELECT against customer_pii.email in your warehouse is not a workflow instance, so the engine never runs and the rule it holds never fires. Not because the rule is wrong, and not because anyone forgot it. There is no process instance for it to attach to.

Now the document half. A policy document governs by being read and acknowledged. An agent has a context window, and the policy is not in it unless something deliberately put it there, at that moment, for that query. Nothing in the document’s own machinery does that.

Both systems can be at 100% compliance and still govern nothing the agent does. The failure mode is not neglect. It is addressing.

The gap has a price. According to Gartner (2026), as reported by CIO, by 2027, 40% of enterprises will have their autonomous AI efforts partly derailed by gaps in governance discovered only after production incidents (Gartner, 26 May 2026). Gaps found only after the incident is what you get when the rule lives somewhere the agent was never going to look, which is why data access governance tools and data classification tools sit closer to the query than either category here.

The declarative-rules community named this seam before AI made the bill due. The Business Rules Manifesto v2.0, published by the Business Rules Group in November 2003 and edited by Ronald G. Ross, Principal at Business Rule Solutions, states in Article 2, “Separate From Processes, Not Contained In Them”: “Rules are not process and not procedure. They should not be contained in either of these.” Twenty-three years old, and not an AI claim.

Policy in the context layer: what has to govern the query instead

If a rule has to hold when an AI agent runs a query, it has to live where the query goes: attached to the data, evaluated at request time. That is a third artifact, distinct from a process model and from a document, and Article 2 is the argument in its original form. What has changed is that the pattern now ships.

Policy-as-code built it first. Open Policy Agent (CNCF, graduated 29 January 2021) decouples the decision from the code that enforces it: per the OPA documentation, a component sends structured input, OPA evaluates it against policy written in Rego, and a decision comes back at request time. Cedar is the adjacent authorization language. Both run in production today.

The literature named the agent-shaped version. In “Policy Cards: Machine-Readable Runtime Governance for Autonomous AI Agents” (Mavračić, arXiv, 28 October 2025), a Policy Card is a machine-readable, deployment-layer standard for operational, regulatory and ethical constraints that “sits with the agent” and tells it what it must and must not do while it runs.

Regulation asks for the same shape. Article 9 of the EU AI Act requires a risk management system to be established, implemented, documented and maintained for high-risk AI systems, running continuously across the lifecycle rather than as a one-time sign-off (for how the obligations phase in, see the EU AI Act summary, which owns that timeline). The NIST AI Risk Management Framework (NIST AI 100-1, 26 January 2023) is the voluntary counterpart, organized around govern, map, measure and manage. A control you can only demonstrate in a document is hard to maintain continuously. A control evaluated every time the system acts is not.

Where the rule lives	Who or what reads it	When it is evaluated	What it governs well	What it cannot reach
Inside a workflow engine	The engine, for process stakeholders	When an instance runs the step	Orchestrated work: approvals, routing, handoffs	Anything that is not a step in a modeled process
In a written policy document	A person, who acknowledges it	When someone reads and attests	Human obligations and auditable proof of who knew what	Any actor that does not read and attest
Attached to the data asset	Any system querying the asset, including an agent	At request time, every query	Access, sensitivity, quality and usage at the point of use	Obligations genuinely about people rather than data

Standing up either category is real work, process discovery on one side and policy inventory on the other, and both take quarters rather than weeks. If agents are in scope, that is the wrong first question, because both projects can finish successfully and leave the third row of that table empty.

What should you ask before you buy either one?

Ask about your own estate, not a vendor’s roadmap. Name the artifact that holds the rule an agent must obey when it queries a given table; if you cannot name it, the rule is not in force at the query, whatever the compliance dashboard says. Then: which of your rules only take effect because a person read something? Which only take effect because a modeled process ran? Those two answers are your exposure. What evaluates the rule at request time, and what does it return, a decision, a masked column, an error? And who can change the rule, and does that change reach the query without a redeploy?

Answering those five is a context engineering problem more than a procurement one, and the same problem as building any enterprise context layer for AI: deciding what a system may see and do, then making that decision available at the tool-call boundary where the agent acts, which is a design concern for any agent harness too. The rule belongs in the enterprise data graph the agent traverses, not in the two places you were shopping.

Check whether your agents can see your rules

A short readiness check across the context an agent needs at query time: definitions, sensitivity, ownership and policy.

Run the Readiness Check

Where does this argument break down?

Three honest counters, and each narrows the claim rather than dissolving it. The first: a workflow engine can call out. A process can invoke a rules engine or a policy endpoint, and externalized machine-readable decisions are an established hybrid pattern. So the precise claim is about default and reach: the default state is a rule encoded inside the engine, and the engine only fires for work it orchestrates. “A workflow engine cannot reach the query” holds up. “Agents cannot read policy” does not, and it is not the claim here.

The second: an agent can read a policy document. Retrieval over policy PDFs is deployed and it works. The narrower claim is that nothing in the document’s own machinery reliably puts the right policy in the context window at the right moment, and that prose does not survive as an enforcement boundary.

The third is sharpest, and it strengthens the conclusion. Machine-readable is not automatically legible: policy expressed in a full programming language can be harder to audit than the paragraph it replaced. The field knows this, which is why Cedar’s designers make readability an explicit goal and describe its policies as meant to be understood by technical and non-technical stakeholders alike. That is the argument for policy living in a graph with human-readable definitions attached rather than as raw code nobody outside engineering opens, and why a compliance automation platform that only emits code is half an answer.

The platforms are also moving: the Business Orchestration and Automation Technologies research that replaced Gartner’s process-suite coverage explicitly includes agentic features. The seam is structural, not a vendor failing, which is why closing it takes a different artifact rather than a better version of the same two.

How Atlan makes policy a node in the Enterprise Data Graph

Atlan holds policy as neither a document nor a process step: it is a graph object attached to the assets it governs, which is what makes a rule reachable when a query runs rather than when someone signs an acknowledgment.

A rule that has to hold for an agent has no natural home in either market: it is not a step in an orchestrated process and not a page for someone to attest. Atlan makes it a node in the Enterprise Data Graph with edges to the assets it governs, traversable at query time. Policy Center is the control plane for creating those policies, monitoring them and handling incidents, and Atlan’s documentation covers six policy types: data quality, data privacy, data security, data lifecycle, data ethics, and definitions and models. Tags and classifications carry the sensitivity signal, with auto-classification and propagation back into the systems where the data physically sits; governance workflows route approvals and exceptions to owners; data contracts sit alongside as first-class context; and Context Engineering Studio validates that agents respect policy rules before production. Per Atlan’s own description of the enterprise context layer, governance follows the agent: an assistant querying through MCP reads from the same governed context layer the data team manages, and “access controls, sensitivity tags, and policies travel with the query.” Policy rules are classification-driven, domain-aware and enforced at the point of discovery.

Orchestrating the process stays with the process engine. In Atlan’s own words, Atlan “is designed to connect with the specialist tools that already govern your data, not replace them”: an approved access request can auto-generate an issue in the workflow tool your team already runs, such as Jira, with status syncing back. What changes is where the data rule lives, not who runs the workflow.

A full account of a written privacy policy becoming automated tagging and classification sits on our data policy setting tools page, and the mechanics for erasure and retention obligations in GDPR compliance automation: both the same move from prose to a rule the estate can evaluate, and the argument for a unified control plane for data.

See policy evaluated at the query, live

Short working demos of the context layer, including how classifications and policies reach an agent's query rather than a document.

Watch the Live Demos

Two markets, one seam, and the rule neither one holds

The phrase names two markets. Business process management software governs the work its engine orchestrates, and does it well. Policy management software governs the people who read and acknowledge a rule, and does that well. The reach of both stops in the same place, short of the query, because both were addressed to a human reader on purpose. So the rule that has to hold when an agent acts belongs in a third artifact: attached to the data, evaluated at request time, changeable without a redeploy. Who owns that artifact is unsettled. In most organizations it falls between the process team, the compliance team and the data platform team, and it is worth asking, before the next agent ships, which of the three will answer for it.

Book a Demo

FAQs about business process and policy management software

1. What is policy management software?

Policy management software authors, versions, distributes and attests written policy, and it governs the people who read and acknowledge it. Its capabilities are drafting and approval, version control, review cycles, distribution and reporting. Its defining capability is attestation: a record that a named person read a specific version of a page.

2. What is business process management software?

Business process management software models, runs and monitors the processes an organization executes, and it governs the work its engine orchestrates. Typical capabilities are process modeling, a workflow engine, task automation, monitoring dashboards and low-code application building. A rule encoded in it takes effect when the engine runs an instance containing that step.

3. What are some examples of BPM software?

Business process management software comes in five recognizable classes: process modeling suites for designing and documenting processes, BPMN workflow engines that execute those models, DMN decision-rules engines for the rules a process consults, CMMN case management systems for non-sequential work, and low-code process platforms bundling all three.

4. What are the 5 pillars of business process management?

There is no standard set of five pillars. The phrasing is a vendor convention with several competing versions, so treat any specific five as one author’s framing rather than a specification. What is standardized is the notation: the Object Management Group publishes BPMN for process models, DMN for decision models and CMMN for case models.

5. What are some examples of policies for data governance?

Atlan’s documentation covers six policy types: data quality, data privacy, data security, data lifecycle, data ethics, and definitions and models. Quality policies set standards for accuracy and completeness, privacy and security policies govern personal data and access, lifecycle policies cover retention and disposal, and definitions policies keep shared terms consistent across teams.

6. Can an AI agent read a policy defined in a BPM workflow?

Not by default. A rule encoded in a workflow engine fires for the process instances that engine orchestrates, so a query that is not a step in a modeled process never triggers it. An agent can be handed policy text and reason over it, but nothing in either system guarantees the right rule is in context at the moment it acts.

Sources

Share this article

Atlan is the Context Layer for AI. Atlan unifies your data, your business knowledge, and the meaning behind your terms into one Enterprise Data Graph that gives every team and every AI agent the trusted context they need, with policy attached to the assets it governs rather than filed as a document. Trusted by Mastercard, Workday, General Motors, CME Group, HubSpot, FOX, Virgin Media O2, Elastic, and 400+ enterprises representing $10T+ in market cap.

Book a Demo Context Studio Live