Most GRC programs are built around frameworks. You pick ISO 27001, NIS2, or SOC 2. You document controls. You pass your audit. Then a year later, you scramble to do it again.

This approach works for producing compliance evidence. What it doesn’t do well is answer the question that actually matters to the business: what would happen if something went wrong?

That gap has a name. It’s the missing business context — and business process management is how you close it.

What a business process actually is in GRC

A business process, for GRC purposes, is a repeating sequence of activities that enables your organisation to deliver value or function operationally. It’s not a department, a system, or a person. It’s the operational unit that your organisation depends on to operate.

Examples:

  • Customer onboarding
  • Financial close and reporting
  • HR recruitment and hiring
  • Software development and deployment
  • Incident response

The key thing about a business process from a security perspective is that it depends on other things to function. It depends on assets — systems, data, infrastructure. It depends on vendors. It is exposed to risks. And it has an owner in the business who cares whether it runs reliably.

This is exactly why business processes are such a powerful anchor for GRC. They sit at the intersection of operational reality and security concern.

Why most GRC programs skip it — and what that costs

In practice, many GRC programs organise around controls and requirements, not around processes. You end up with a control for “backup management,” a control for “access management,” a risk for “ransomware.” But nowhere in the program is it clearly stated: if our invoicing process goes down, here is exactly what’s at stake and why.

The result is a security program that’s hard to explain to leadership, hard to prioritise internally, and disconnected from the reality of how the business operates.

Three specific problems show up repeatedly:

1. Risk prioritisation becomes a technical exercise. When risks are assessed in isolation — without being tied to which processes they threaten — the severity ratings tend to reflect technical intuition rather than business impact. A highly technical risk to a rarely-used system ends up rated higher than a simpler risk to the process that processes your payments.

2. Asset and vendor decisions lose context. Without connecting assets and vendors to the processes they support, it’s hard to explain why some assets or vendor relationships deserve more investment and scrutiny than others. Why does this particular SaaS tool need a thorough security review? Because it’s the only system used in your customer onboarding process, and if it’s down, new revenue stops.

3. Security teams own the wrong conversations. When GRC lives only in the security team, business stakeholders are at arm’s length. Process-level framing is what brings them in. A process owner understands and cares about their process. They’re far less engaged by a control titled “logical access management.”

The three connections that change everything

Once business processes are documented, three connections transform your GRC program from a compliance exercise into an operational model.

1. Assets → Business processes

Linking assets to the processes they support answers the question: if this asset fails or is compromised, what stops working?

This is foundational for several reasons. First, it makes criticality ratings meaningful. An asset that supports a single internal workflow has a different risk profile than one that three critical processes depend on. That difference should drive how much protection and monitoring that asset gets.

Second, it reveals concentration risk — where multiple critical processes all depend on the same asset. This is exactly the kind of systemic vulnerability that asset inventories alone don’t surface. You can have a complete and well-maintained asset inventory and still have no idea that a single SaaS tool or on-premises server is a single point of failure for half your operations.

Third, it enables better business continuity planning. When you know which processes an asset supports, you can design recovery prioritisation based on operational impact rather than technical preference.

2. Vendors → Business processes

Third-party dependencies are one of the most significant sources of operational risk for most organisations — and one of the hardest to manage in a way that resonates outside the security team.

Connecting vendors to business processes gives that risk a business context. It turns “vendor X has an expired contract and no recent security assessment” into “the process that handles all your customer data processing has an unmonitored external dependency.”

This framing does two things. It makes vendor risk decisions easier to escalate, because the business impact is visible. And it forces more honest conversations about how many processes actually depend on external vendors — which is often more than anyone expected when looking at a vendor list alone.

It also helps with prioritisation within vendor management. Not all vendors need the same level of scrutiny. Connecting vendors to processes makes it straightforward to tier your vendor review effort by what’s operationally at stake.

3. Risks → Business processes

Connecting risks to business processes is how you turn a risk register into a prioritisation tool.

When a risk is only associated with an asset or a control, the question of how seriously to take it is often answered by gut feel or framework severity tables. When a risk is connected to a business process, the question becomes concrete: what is the impact to this process if this risk materialises, and how likely is that?

This also brings the process owner into the risk conversation in a meaningful way. They’re not reviewing an abstract list of threats. They’re reviewing the risks to the process they own and operate. That’s a conversation they can engage with and contribute to — which is exactly how GRC should work.

What you actually gain: visibility, prioritisation, accountability

The practical gains from this connected model show up in three places.

Visibility. You can look at a business process and immediately see its full dependency chain — which assets support it, which vendors it relies on, which risks threaten it, and whether any controls protecting it are failing or overdue. That’s a level of visibility that no amount of spreadsheet management produces.

Prioritisation. Security work is always competing for time and attention. When everything is connected to processes, prioritisation becomes tractable. You work on the things that protect the most operationally critical processes first. That’s a principle you can explain to anyone in the organisation.

Accountability. Business process owners are, by definition, accountable for whether their process runs reliably. When your GRC model connects risks and controls to their processes, you can involve them naturally — they have skin in the game, and the questions you’re asking them are directly relevant to their responsibilities. This is how security stops being something the security team does in isolation.

What the frameworks actually expect

ISO 27001 doesn’t prescribe business process documentation by name, but it’s embedded throughout the standard. Clause 4 requires understanding the context of the organisation and its interested parties. The scope definition in Clause 4.3 requires understanding which processes are in scope. Risk assessment in Clause 6 requires that risks be assessed in context — which inevitably means understanding what you’re trying to protect and why it matters.

NIS2 is more explicit. It requires entities to have a clear understanding of their critical business functions and the assets and services supporting them. Supply chain risk management under NIS2 also presupposes that you know which processes depend on which third parties.

In practice, auditors under both frameworks increasingly expect to see the connection between your compliance posture and how your organisation actually operates. A risk register full of technical controls, disconnected from the business, is harder to defend than one that clearly shows which operational processes are protected and how.

Common mistakes to avoid

Documenting processes but not connecting them. A list of business processes that isn’t connected to assets, vendors, and risks provides a framework for communication but no operational value. The connections are what make it useful.

Making processes too granular. A business process in a GRC context is not a workflow diagram. You don’t need every step documented. You need a clear enough description to identify what it does, who owns it, and what it depends on. Aim for 5–20 core processes rather than 200 sub-processes.

Assigning process ownership to IT. IT may manage the systems that support a process, but the process owner should be the business stakeholder who is accountable for that function. Without a business owner, the process sits in IT’s domain and never becomes a shared responsibility.

Treating it as a one-time mapping exercise. Processes evolve. New tools are introduced, vendors change, and responsibilities shift. Business process documentation needs to be a living part of your GRC program — updated when things change, reviewed regularly, not produced once and filed.

Ignoring concentration risk. Once you’ve mapped processes to assets and vendors, look specifically for patterns where many processes depend on a small number of shared dependencies. Those are your highest-priority resilience concerns, and they’re invisible without this connected view.

How Kordon approaches this

In Kordon, business processes are a first-class object in the platform — not a documentation appendix or a section in a policy. Every process can be connected directly to the assets that support it, the vendors it relies on, the risks that threaten it, and the controls that protect it.

The health status model shows you in real time whether a process is in good shape. If a connected vendor’s contract has expired, or an asset has an unresolved finding, or a control protecting the process has a failing or overdue task, the process itself reflects that state. You don’t have to chase down status across multiple views — the process is the lens through which everything is visible.

This matters particularly when you have business stakeholders who need to understand their exposure without needing to learn GRC concepts. Process owners in Kordon can see the health of their process, the open findings related to it, and the tasks assigned to them — all in context. That’s the kind of involvement that makes a GRC program genuinely collaborative rather than just compliant.

For information security managers, the connected model also simplifies audit preparation considerably. When an auditor wants to understand your risk posture, you can show them a process, walk through its dependencies, and trace the controls and evidence back through the chain. It’s a narrative that makes sense to people who care about how the business operates — because it’s built around how the business actually operates.

Where to start

If you don’t have business processes mapped yet, start small and aim for coverage over detail:

  1. List your 5–10 most critical processes — the ones whose disruption would have the highest business impact. You can expand from there.
  2. Identify the owner for each process — find the person accountable for that function, not the IT team that manages the systems.
  3. Connect the obvious dependencies — which assets and vendors does each process rely on? Start with the ones that would cause the process to stop if they failed.
  4. Map the risks that directly threaten each process — not every risk in your register, just the ones with a credible path to disrupting that specific process.
  5. Revisit and expand — as the model grows, the connections become more valuable. But even a basic connected model is more useful than a flat inventory.

The goal isn’t a perfect map. It’s a working model that helps you make better decisions about where to focus, and helps the business understand what security is actually protecting.