Screenata

Beyond SOC 2

What are the 4 P's of BCP?

August 18, 20263 min read

What are the 4 P's of BCP?

The four P's of business continuity planning are People, Processes, Premises, and Providers. Each names a category of resource that a critical business function depends on: who does the work, how the work gets done, where it happens, and who you rely on outside the organisation. A business impact analysis works through all four for each critical function rather than stopping at technology.

The four P's

PThe question it forcesWhat gets missed
PeopleWho can perform this function, and who else could?Single points of knowledge with no documented process
ProcessesWhat steps and systems does it require?Undocumented manual steps only one person knows
PremisesWhere does it happen, and what if that is unavailable?Assumed remote-work capability that has never been tested
ProvidersWhich suppliers does it depend on?Fourth parties, the suppliers of your suppliers

Why the P's exist rather than a systems list

Most continuity plans are written by technical teams and reflect that: they cover servers, backups, and failover regions. That work addresses part of Processes and part of Premises. It leaves People and Providers untouched.

The gaps auditors and real incidents surface most often are in those two. A function that only one person knows how to perform is a continuity risk that no amount of infrastructure redundancy addresses. A critical supplier with no alternative is the same problem one step removed.

Business impact analysis, and the two objectives it sets

The BIA comes before the plan. It identifies critical functions, then determines for each how long it can be unavailable before the impact becomes unacceptable. That produces two numbers:

  • RTO, recovery time objective. How quickly the function must be restored.
  • RPO, recovery point objective. How much data loss is tolerable, measured in time.

These two numbers are what a plan is designed against, and they are what an auditor asks for. A continuity plan with no stated RTO or RPO has not been designed against anything.

The BIA is commonly described in three stages: identify critical functions, assess impact over time, and set recovery objectives.

Where this appears in SOC 2 and ISO 27001

  • SOC 2 Availability category: A1.2 covers environmental protections, backup, and recovery infrastructure; A1.3 requires testing recovery procedures. A Security-only scope does not test continuity directly.
  • ISO 27001 Annex A 5.29 and 5.30 cover information security during disruption and ICT readiness for continuity.

In both cases the artifact auditors ask for is the same: evidence the plan was tested, not merely written. An untested plan and no plan produce similar outcomes during an actual incident, and an auditor treats them similarly too.

Connect and see

See your SOC 2 with your real systems.

Connect GitHub and cloud read-only. Vera shows your control matrix, policy gaps, and prioritized next actions before you commit to anything.