How do you check whether your continuity plan approval process has a segregation of duties gap?

Open your plan approval workflow and check whether the approver can ever be the same person as the author. If it can, under the current configuration or role assignment, you have a segregation of duties finding waiting to be written by someone else, most likely an auditor.

What do you do if your platform cannot separate plan authorship from approval?

Treat it as a product constraint, not a practice to adopt. Name a compensating control, such as a mandatory independent sign-off step recorded outside the plan owner's own workflow, rather than accepting author-as-approver as how the tool works.

Who should review and approve a continuity plan?

Not the person who wrote it, and this is worth checking today, because the default approval routing in several widely deployed GRC products sends the plan back to the plan owner who authored it. That is a segregation of duties failure sitting in a shipped configuration, and it is usually discovered during an audit rather than during design.

Published 18 September 2026

Maximilian Bazzi, Founder and CEO

The carried fact this section exists for

Open your continuity plan approval workflow today and check one thing: whether the person who authored the plan can also be the person who approves it. In several widely deployed governance, risk and compliance platforms, the default configuration routes a completed plan back to the plan owner for sign-off, because the plan owner is also, by default, the approver role. That is a segregation of duties failure sitting inside a shipped default, not a policy decision anyone made deliberately, and it is usually found during an audit rather than caught during design.

Why review and approval need two different people

Review belongs to someone accountable for the service the plan protects but independent of the plan's authorship: someone positioned to ask whether the plan is realistic and complete, without the natural reluctance an author has to mark their own work as insufficient. Approval belongs to the level that actually owns the disruption tolerance the plan is written against, which is a governance decision about acceptable risk, not a technical sign-off that the document is well formed. Neither role should default to the plan's own author, for the same reason no organisation would accept an author approving their own expense claim.

Naming the pattern without naming a vendor

This finding originated as a specific, product-level observation, and it generalises cleanly: shipped role configurations in GRC and BCM platforms are built for speed of deployment, and separating authorship from approval is exactly the kind of governance nuance that gets left to the customer to configure, or gets missed. The pattern is common across shipped configurations generally, not a flaw specific to one product, which is precisely why it is worth checking regardless of which platform a given organisation runs.

What to do where the platform genuinely cannot separate the roles

Some platforms make separating plan ownership from approval difficult or impossible without custom configuration. Where that is the case, the honest position is to name it as a product constraint to be compensated for, not a practice to adopt because the tool makes it convenient. A compensating control, such as a mandatory independent sign-off step recorded and evidenced outside the plan owner's own workflow, closes the gap without waiting for a platform change.

Where teams commonly run into difficulty

The common failure is discovering this during an internal or external audit rather than during design, at which point the finding reads as a control failure rather than an unconfigured default. Checking the approval routing once, early, and naming a compensating control if the platform needs one, is materially cheaper than remediating it after an auditor has written it up.

How Bazzi Consulting helps

We check plan approval routing for exactly this gap as part of embedding the framework, and design the compensating control your platform needs if it cannot separate authorship from approval on its own. See making the framework run.