BCDR and IT Operations: "Show Me the BCDR!" – Business Continuity in the Age of PHP2Shell

Update, October 2026: I've completely reworked this page. Around the PHP2Shell vulnerability, the same questions came up so many times over the past few days that I decided to gather in one place what BCDR means in practice, and why it's the first thing I want to see in an incident.

Over the past few days I've heard the same question a hundred times: "Csaba, what should we do? What do you recommend?" And every time I asked the same thing back: what does the BCDR say? Show me the BCDR.

The answer was almost always the same. "We don't have one." Or: "We do, but it's old – it hasn't been updated in years." Or the most honest one: "The what?"

And that's the point. With a critical vulnerability, the question isn't whether a fix exists – for PHP2Shell, it does. The question is whether the organisation knows how much risk it can bear, how long a system can be down, who decides on a shutdown, and what of all this the provider has committed to. The BCDR answers those questions. Without a BCDR, panic makes the decision.

The People Who Called – and Where I'm the Security Officer

A great many people called me over the past few days who aren't my clients. From companies where CSE Business Kft. isn't the IT operations partner and I'm not the CISO. I'm happy to help, but in those cases I can't see into the systems, the contracts or the risks – and responsibly, I can't say anything other than: let's look at the BCDR.

Where I provide information security officer / CISO services, the situation is completely different:

Question	With a living BCDR	Without one (or with an old one)
Where does PHP run?	The system inventory tells us in minutes	Days of searching, "forgotten" servers
How critical is the system?	We know from the BIA, with RTO and RPO recorded per system	"They're all important" – meaning none of them are prioritised
Who decides on a shutdown?	Roles and decision rights defined in advance	Everyone waits for someone else
Is there a WAF?	Yes, with rules, temporarily tightened within hours	"I think there's a firewall"
What has the provider committed to?	SLA, patch deadlines and notification duties in the contract	Nobody knows – the contract is in a drawer
Rollback if things go wrong?	Tested backups, rehearsed restores	"There's a backup" – but nobody has ever tried restoring it

What Is BCDR?

BCDR is the umbrella name for two closely linked disciplines:

Business Continuity (BC): how the organisation keeps working during a disruption. Which processes are critical, what the workaround is, who does what, how we communicate.
Disaster Recovery (DR): how IT systems and data are restored after an outage, an attack or a disaster – in what order, how fast, and with how much data loss.

Put simply: BC is about the business surviving, DR is about IT coming back. Neither works without the other.

The Terms There's No BCDR Without

Term	Meaning	Example
BIA – Business Impact Analysis	What happens if a process or system goes down, and what it costs per hour	A web shop outage costs X million forints in lost revenue per hour
RTO – Recovery Time Objective	How quickly the system has to be working again	The patient admission system's RTO is 4 hours
RPO – Recovery Point Objective	The maximum data loss, expressed in time	RPO of 1 hour = at most the last hour of data is lost
MTPD – Maximum Tolerable Period of Disruption	The longest outage after which the organisation suffers lasting damage	After three days, partners terminate their contracts
Risk appetite and tolerance	How much risk management is willing and able to accept	"We won't accept an outage longer than one day"
SLA – Service Level Agreement	The service level the provider commits to in the contract	99.9% availability, 4-hour fault resolution

What Availability Means in Numbers

The percentages in SLAs look very similar on paper. In reality the difference is huge:

Availability	Permitted downtime per year	Per month, approx.
99%	3.65 days	7.3 hours
99.9%	8.76 hours	43.8 minutes
99.95%	4.38 hours	21.9 minutes
99.99%	52.6 minutes	4.4 minutes
99.999%	5.26 minutes	26 seconds

So a 99% SLA permits more than three days of downtime a year – contractually. It's worth checking what we signed.

Three Options – Until I See the BCDR

In short: until I see the BCDR, the risk and the company's tolerance, I give three options. There is no fourth – "it'll be fine somehow" isn't an option.

Option 1 – Shut it down, patch it, pentest it, restart it.

You take the web application or web portal offline. The PHP engine is updated, it's checked for existing compromise, a penetration test runs, and only then does it go back online. This is the safest route – the price is the outage. If the BIA says the system can tolerate it, this is the right decision.

Option 2 – You accept the responsibility and the risk, together with the information security officer / CISO.

The system keeps running, but as a conscious, documented decision. The information security officer / CISO knows exactly how much the organisation can tolerate, the risk is written down, the compensating controls (WAF, tightened rules, enhanced monitoring) are in place, and management formally accepts the risk with a signature – with a deadline, not forever.

Option 3 – An informed decision, knowing the BCDR, the risk and the contracts.

You know the BCDR document and the risk. You know what contracts you have with your providers and what they commit to: how fast they deploy critical updates, when they notify you, who pays for the damage. You decide on that basis – and if the provider doesn't deliver, you know what you can hold them to.

What all three options have in common: the PHP engine has to be updated. The only question is whether, until then, the system is down or keeps running with a documented, accepted risk and compensating controls. And in either case the responsibility lies with the organisation's management – not with the IT operator, and not with the provider.

IT Outsourcing: A Contract Is Not the Same as Security

Today, most companies' IT is partly or fully outsourced. That's fine – if it's done properly. In most cases an IT outsourcing contract comes with additional schedules and terms: SLAs, availability, fault resolution times, and the whole service is aligned with the client's needs, BCDR and SLA expectations.

Unfortunately, every day we come across IT contracts where none of this is documented. Worse, neither the client nor the IT provider understands the systems and the risks. The client believes the provider "handles everything", and the provider does what the contract says – which is often little more than "call us and we'll take a look".

Shared Responsibility: Who Actually Does What?

For every SaaS, PaaS or other cloud service you use, the question is the same: where does the provider's responsibility end, and where does ours begin?

Area	Own server	IaaS	PaaS	SaaS
Physical infrastructure	You	Provider	Provider	Provider
Operating system, updates	You	You	Provider	Provider
Runtime (e.g. PHP)	You	You	Provider	Provider
Application	You	You	You	Provider
WAF, edge protection	You	You	Per contract	Provider – but you have to verify it
Data, access, permissions	You	You	You	Shared
BCDR, risk acceptance	You	You	You	You

The last row is the most important one. You can outsource the task, but not the responsibility. If a SaaS provider goes down or gets breached, it's your customers' data at risk, and it's your company that has to explain – to customers, to the authorities, to partners.

And you don't need the cloud for this. A business application or website hosted on your own server has to be just as secure: updated, behind a WAF, backed up, and included in the BCDR.

The Companies' Fault – and Where Is the Security Officer, the CISO?

Every day I see web applications and websites without a WAF, and IT operations colleagues who skip the security part entirely. In my view this is primarily not their fault but the companies': they hire the wrong specialists and the wrong IT operators because it's cheaper.

And then the fair question is: where is the information security officer, where is the CISO? If an organisation doesn't have one – or has one only on paper – nobody asks the most important question: what's out there on the internet, who protects it, and what happens if a PHP2Shell arrives tomorrow? I've written in detail about WAFs and systems running without one on a separate page.

What Every Business Leader Using IT or SaaS Services Should Watch Out For

These questions are worth putting to every provider – before signing, and every year after. If a provider can't answer them, that is an answer in itself.

SLA and availability: is there a written SLA, what percentage, what counts as an outage, and what's the penalty if it isn't met?
RTO and RPO: how quickly is the service restored, and how much data can be lost? Does this match our own BIA?
Security updates: how quickly are critical fixes deployed? Is there a written commitment (a patch SLA)?
WAF and penetration testing: does the service run behind a WAF? Is there regular, independent penetration testing, and can we get a management summary?
Backups: how often do they back up, do they test restores, and is there an offline or immutable copy against ransomware?
Incident notification: how soon will they notify us of an incident, and who is the 24/7 contact?
Data location and data protection: where is the data stored (EU / EEA?), who can access it, and is there a GDPR data processing agreement?
Certifications: ISO/IEC 27001, ISO 22301 (business continuity), SOC 2 – and are they current?
Subcontractors: who are the provider's own suppliers, and do the same terms apply to them? Do we have audit rights?
Access: who holds administrator access, is multi-factor authentication mandatory, and what happens if the key person leaves?
Exit plan: if we terminate or the provider goes out of business, how, in what format and how quickly do we get our data back?
Regulation: are we subject to Hungary's cybersecurity act transposing the NIS2 directive (Act LXIX of 2024), DORA in the financial sector, or healthcare data rules – and does the provider operate accordingly?

What a Living BCDR Contains

A BCDR isn't a 200-page document written once for an audit. It's only worth something if you can pull it out during an incident at dawn and it tells you exactly what to do. The minimum:

System inventory and dependencies: what runs where, and what depends on what – including cloud and SaaS services.
BIA: the critical processes and systems, with RTO and RPO.
Roles and decision rights: who decides to shut a system down, who communicates, who the deputy is.
Incident response and communication plan: who we notify, when, and through which channel – customers, authorities, partners.
Offline contact list: reachable even when email and the phone system are down.
Backup and restore: tested, with at least one offline or immutable copy.
Supplier list: contracts, SLAs, contacts, escalation paths.
Emergency change process: how a critical fix gets deployed quickly but still in a controlled way, with a rollback plan.
Exercises: at least one DR test or tabletop exercise a year.
Review: annually, and after every significant change or incident.

I saw the same gap in the 40+ hour Autosecurit / Skyguard outage: when there's no BCDR, an outage doesn't last hours, it lasts days.

What to Do Now About PHP2Shell

Get out the BCDR. If there isn't one, or it's old, that's the first task – after this incident too.
Ask your IT provider and every SaaS provider whether they're affected, whether they've patched, and whether the service runs behind a WAF. Ask in writing.
Choose one of the three options – consciously, documented, with a deadline.
See what it means for your type of website in the risk handbook, and the technical steps on the PHP2Shell page.

                            The lesson in one sentence: a BCDR isn't paper gathering dust in a drawer, it's the page you pull out on a night like this – and if there isn't one, the organisation doesn't decide; chance does.
                        

If you'd like us to review your BCDR and your IT and SaaS contracts, or you need information security officer / CISO services, get in touch on the contact page, via CSE Business or on LinkedIn.

BCDR and IT Operations: "Csaba, What Should We Do?" – "Show Me the BCDR!"