Operational Risks in Processes: Bus-Factor & Ownerless Workflows

A major operational incident rarely happens without prior warning signs. More often than not, it results from a combination of structural flaws that were ignored or simply never formalised: a critical process only one person understands, a procedure that nobody owns, documentation that has not been reviewed in two years. For CIOs and CISOs at SMEs and mid-market companies, identifying these risks before they become incidents is a business continuity challenge — and increasingly, a regulatory compliance one.

Why Business Processes Are an Underestimated Risk Surface

Operational risk management typically focuses on technical infrastructure: server availability, access continuity, cyber-attack resilience. That is entirely legitimate. But business processes themselves represent a risk surface that organisations rarely assess with the same rigour.

A process is risky not only when it is poorly designed, but also when:

• it depends on the tacit knowledge of a single individual,
• no identified owner can decide on its evolution or suspension,
• the associated procedures have not been reviewed recently enough to reflect operational reality.

These three situations correspond to distinct risk signals, each examined below. They sit at the core of the automatic risk detection offered by UrbaHive in its business process mapping module.

Bus-Factor — or Single Point of Knowledge: When Everything Depends on One Person

Definition

The "bus-factor" (sometimes called the "truck factor") refers to the minimum number of people whose sudden absence — accident, resignation, extended sick leave — would paralyse a process or project. A bus-factor of 1 means a single person holds all the knowledge needed to run a process. That is a critical risk.

In technical teams, the concept is well understood. In the business processes of SMEs and mid-market companies, it is rarely measured. Yet bus-factor-1 situations are common: the sole accountant who knows how to generate bank reconciliation reports in the ERP, the payroll manager who has all the overtime calculation rules memorised, the executive assistant who single-handedly manages relationships with three strategic suppliers.

Real-World Consequences

When that person is absent, the organisation faces three options, all bad: wait for their return, hand the task to someone who does not know the process and risk errors, or urgently bring in costly external support.

From a NIS2 compliance perspective, a bus-factor-1 process supporting an essential service is a direct non-conformity with the directive's business continuity requirements.

How to Detect It

In UrbaHive, each process step is linked to an identified actor. The system automatically flags steps where only one actor is referenced across the entire process with no designated backup. These steps are reported as "single point of knowledge" risks in the management dashboard.

Ownerless Processes: An Invisible Governance Risk

What Is an Orphan Process?

An ownerless process is one for which no individual or function formally assumes responsibility: neither for maintaining its documentation, nor for deciding on changes, nor for validating its day-to-day execution.

Orphan processes typically arise in three situations:

1. Reorganisation: a process owner changes role or leaves the organisation, and no successor is named.
2. Informal creation: the process was set up pragmatically, with no formal governance defined around it.
3. Unclear boundaries: the process sits at the border of two departments, each assuming the other is responsible.

Why This Is Dangerous

An ownerless process receives no review, no continuous improvement, and no alert when something goes wrong. It drifts gradually — unnoticed — until an incident reveals the gap between the written procedure and actual practice.

For CISOs, ownerless processes are particularly concerning when they involve access management, security incident handling, or personal data processing. The absence of an owner makes post-incident investigation difficult and compliance demonstration — whether under GDPR or NIS2 — nearly impossible. See our article on IT mapping and cybersecurity for more on this.

Detection in UrbaHive

UrbaHive automatically flags as a risk any process for which no owner is recorded in the map. Detection applies both at the process level and at the individual step level, making it possible to identify situations where a process has a global owner but contains orphaned steps.

Documentation Obsolescence: When Your Procedures No Longer Reflect Reality

A Systemic Problem in SMEs

Process documentation ages poorly. Organisations document their processes during certification projects (ISO 9001, ISO 27001), ERP migrations, or audit preparations — and then stop updating them. Twelve months later, written procedures no longer match actual practices, referenced applications have changed, and the actors involved have shifted.

Gartner research estimates that 60 to 80 percent of process documentation loses its operational value within 18 months of being written if it is not actively maintained. In SMEs and mid-market companies without a formalised documentation governance process, that proportion is likely even higher.

Associated Regulatory Risk

For organisations subject to NIS2 or sector-specific frameworks (healthcare, finance, defence), stale process documentation constitutes a direct compliance risk. Auditors rely on documentation to assess risk management; documentation that contradicts observed practices is a major red flag.

In the context of IT landscape management, up-to-date process documentation is also a prerequisite for any impact analysis during an application migration or IT overhaul.

Detection in UrbaHive

UrbaHive automatically flags processes that have not been reviewed within the past 12 months. This threshold is configurable based on the organisation's regulatory requirements. Detection relies on the last-modified date of the process in the platform, which assumes teams keep their maps current — a good habit in its own right.

How to Address These Risks: From Detection to Action Plan

Identifying a risk is only a first step. Here is a structured approach for each signal type:

Bus-factor 1

1. Identify the affected processes and estimate their criticality (volume, impact if interrupted).
2. Set up a backup arrangement: designate a trained substitute and document the process in enough detail to enable a rapid handover.
3. Schedule regular rotation to maintain the substitute's competency.

Ownerless process

1. Assign an interim owner within 48 hours of detection.
2. Conduct a quick review of the process to confirm it reflects reality and update the actors involved.
3. Add the review to the annual governance calendar.

Stale documentation

1. Schedule a review with the process stakeholders.
2. Update the steps, actors, and linked applications in the map.
3. Define a review frequency appropriate to the process's criticality (annual, semi-annual, quarterly).

The optimisation score (out of 100) calculated by UrbaHive incorporates these risk dimensions to prioritise actions. The management dashboard tracks risk evolution over time and measures the effectiveness of corrective actions.

Conclusion

Bus-factor, ownerless processes, and documentation obsolescence are three operational risk signals that appear in no technical monitoring tool, yet can have consequences as severe as a server outage or a security breach. For CIOs and CISOs at SMEs and mid-market companies, identifying and addressing them is a condition of operational resilience — and, increasingly, a regulatory requirement.

Start for free on UrbaHive and automatically detect hidden risks in your business processes with the process editor.

FAQ

Q: Does bus-factor apply only to technical or IT processes?

A: No. The concept applies to any process where operational knowledge is concentrated in a single individual, whether in finance, HR, sales, or logistics. SME business processes are often more exposed than technical processes precisely because they are less documented.

Q: How do you make the business case for addressing these risks, which are often seen as non-urgent?

A: The most effective argument is business continuity: ask how much a day's interruption of the process in question would cost. If that figure exceeds the cost of documenting the process and training a backup, the decision is straightforward. In a NIS2 or ISO 27001 context, the regulatory dimension adds further weight.

Q: What is the recommended review frequency for critical processes?

A: For processes supporting essential or regulated services, a semi-annual review is recommended. For standard processes, an annual review is the minimum. UrbaHive automatically flags processes that exceed the 12-month threshold without a review.

Q: Can a process have multiple owners?

A: Yes, but this can dilute accountability. A good practice is to distinguish the business owner (who decides on rules and changes) from the operational manager (who oversees day-to-day execution). The key is that at least one person is identified as the decision-maker.

Q: Can UrbaHive detect risks linked to critical applications with no technical backup?

A: Yes. UrbaHive links processes to the applications that support them. If an application is the sole support for a critical step and no redundancy is documented in the application map, that risk can be surfaced in the dashboard.