--- question: "What are the 4 P's of BCP?" title: "What Are the 4 P's of BCP" seoTitle: "The 4 P's of Business Continuity Planning" summary: "The 4 P's of business continuity planning are People, Processes, Premises, and Providers. They are the four categories of resource a business impact analysis examines: who does the work, how it gets done, where it happens, and who you depend on externally. A continuity plan that covers only IT systems has addressed part of one P, which is the most common gap auditors find." publishedAt: "2026-08-18" keywords: - "4 P's of BCP" - "business continuity planning" - "business impact analysis" - "people processes premises providers" - "five elements of a business impact analysis" - "three stages of BIA" pillar: "Beyond SOC 2" faqs: - question: "What are the four P's of business continuity?" answer: "People, Processes, Premises, and Providers. Each names a category of resource a critical business function depends on, and a business impact analysis works through all four rather than stopping at technology." - question: "What is a business impact analysis?" answer: "The exercise that identifies critical business functions, determines how quickly each must be restored, and establishes recovery time and recovery point objectives. It comes before the continuity plan, because it decides what the plan needs to protect." - question: "Does SOC 2 require a business continuity plan?" answer: "It depends on scope. Under the Availability trust services category, yes: A1.2 and A1.3 cover recovery infrastructure and testing. A Security-only SOC 2 does not test continuity directly, though CC7 and CC9 touch on incident and risk handling." --- ## 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 | P | The question it forces | What gets missed | |---|---|---| | **People** | Who can perform this function, and who else could? | Single points of knowledge with no documented process | | **Processes** | What steps and systems does it require? | Undocumented manual steps only one person knows | | **Premises** | Where does it happen, and what if that is unavailable? | Assumed remote-work capability that has never been tested | | **Providers** | Which 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.