A business continuity plan (BCP) is a documented strategy that defines how an organisation will maintain essential functions during and after a disruption — whether from cyberattacks, natural disasters, or supply chain failures — and is required under regulations such as NIS2, DORA, and ISO 22301.
When a ransomware attack shut down Colonial Pipeline for six days in 2021, fuel shortages cascaded across the US East Coast. When CrowdStrike's faulty update brought down 8.5 million Windows devices in July 2024, airlines, hospitals, and banks scrambled to restore operations manually. Neither event was unforeseeable — but the organisations that recovered fastest were the ones with tested business continuity plans.
A business continuity plan (BCP) is a documented strategy for maintaining essential business functions during and after a disruption. It's not just a cybersecurity document — BCPs cover natural disasters, pandemics, supply chain failures, key person loss, and any event that threatens your ability to operate. Under modern regulations like NIS2, DORA, and ISO 22301, business continuity planning is a compliance requirement, not a best practice.
This guide provides a complete, practical framework for building a business continuity plan — from business impact analysis through recovery strategies to testing and maintenance.
| Quick Reference | Details |
|---|---|
| What is a BCP? | A documented plan for maintaining essential business functions during and after a disruption |
| Key standard | ISO 22301:2019 (Security and resilience — Business continuity management systems) |
| Key framework | BCI Good Practice Guidelines (GPG) |
| Core components | Business Impact Analysis (BIA), risk assessment, recovery strategies, plan documentation, testing |
| DORA requirement | ICT business continuity policy; ICT response and recovery plans; annual testing |
| NIS2 requirement | Business continuity and crisis management (Article 21(2)(c)) |
| ISO 27001 alignment | Annex A.5.29 (Information security during disruption), A.5.30 (ICT readiness for business continuity) |
| Testing frequency | At least annually; more frequently for critical processes |
| Key metric: RTO | Recovery Time Objective — maximum acceptable downtime |
| Key metric: RPO | Recovery Point Objective — maximum acceptable data loss |
Key Takeaways
- A business continuity plan ensures your organisation can maintain essential operations during and after a disruption — whether cyberattack, natural disaster, or supply chain failure
- The Business Impact Analysis (BIA) is the foundation of all BCP planning — it identifies your critical processes, their dependencies, and the impact of their disruption
- RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are the two most important metrics — they drive all recovery strategy decisions
- NIS2 and DORA both mandate business continuity planning with specific testing requirements
- ISO 22301 is the international standard for Business Continuity Management Systems — pursuing certification demonstrates mature BCP capability
- A BCP is only valuable if it's tested regularly — untested plans fail when you need them most
- Crisis communication is a critical but often overlooked component — who says what, to whom, and when
- Business continuity and incident response are complementary: incident response handles the security event; BCP handles the business operations continuity
Table of Contents
- What Is a Business Continuity Plan?
- BCP vs. Disaster Recovery vs. Incident Response
- Regulatory Requirements for Business Continuity
- The BCP Development Lifecycle
- Step 1: Business Impact Analysis (BIA)
- Step 2: Risk Assessment
- Step 3: Recovery Strategy Development
- Step 4: Plan Documentation
- Step 5: Testing and Exercises
- Step 6: Maintenance and Review
- Business Continuity Plan Template
- BIA Template
- Crisis Communication Plan
- Common BCP Mistakes
- Frequently Asked Questions
- Related Resources
What Is a Business Continuity Plan?
A business continuity plan is a documented set of procedures and information that enables an organisation to:
- Identify which business processes are critical to survival
- Assess the impact of disruptions to those processes
- Develop strategies to maintain or quickly restore critical operations
- Document the specific actions, responsibilities, and resources needed
- Test the plan regularly to ensure it works
- Maintain the plan as the organisation and threat landscape evolve
A BCP is not a single document — it's a programme comprising multiple components that work together.
BCP Programme Components
| Component | Purpose |
|---|---|
| Business Impact Analysis (BIA) | Identifies critical processes, dependencies, and the impact of their disruption |
| Risk Assessment | Identifies threats that could cause disruptions |
| Recovery Strategies | Defines how critical processes will be maintained or restored |
| Plan Document | Detailed procedures for response and recovery |
| Crisis Communication Plan | How to communicate during a crisis (internal and external) |
| IT Disaster Recovery Plan (DRP) | Technical recovery procedures for IT systems and data |
| Testing Programme | Regular exercises to validate the plan |
| Training Programme | Ensuring staff know their roles during a disruption |
BCP vs. Disaster Recovery vs. Incident Response
These three disciplines are related but distinct:
| Aspect | Business Continuity Plan | Disaster Recovery Plan | Incident Response Plan |
|---|---|---|---|
| Focus | Maintaining business operations | Recovering IT infrastructure and data | Responding to security incidents |
| Scope | Entire organisation — people, processes, technology, facilities | IT systems, applications, data | Security events and breaches |
| Triggered by | Any disruption (natural disaster, pandemic, supply chain, cyber, facilities) | IT infrastructure failure or loss | Security incident detection |
| Key question | "How do we keep the business running?" | "How do we get IT systems back online?" | "How do we detect, contain, and eliminate the threat?" |
| Key metrics | RTO, RPO, MTPD (Maximum Tolerable Period of Disruption) | RTO, RPO | MTTD, MTTR |
| Key standard | ISO 22301 | ISO 27031 | NIST SP 800-61 |
| Relationship | Umbrella plan; includes DRP as IT component | Subset of BCP; focused on technology | Feeds into BCP when incidents cause business disruption |
Regulatory Requirements for Business Continuity
| Regulation | Requirement | Specific Articles |
|---|---|---|
| NIS2 | Business continuity and crisis management, including backup management and disaster recovery | Article 21(2)(c) |
| DORA | ICT business continuity policy; ICT response and recovery plans; testing at least annually | Articles 11–13 |
| ISO 27001 | Information security aspects of business continuity management; ICT readiness for business continuity | Annex A.5.29–A.5.30 |
| SOC 2 | Availability criteria — maintaining system availability consistent with commitments | A1.1–A1.3 |
| PCI DSS 4.0 | Business continuity plan that covers at minimum the annual review and testing | Requirement 12.10.2 |
| Basel III / Banking regulations | Operational resilience; critical business services identification; impact tolerances | Varies by jurisdiction |
| FCA (UK) | Operational resilience; impact tolerances for important business services | PS21/3 |
The BCP Development Lifecycle
┌─────────────────────────────────────────────────┐
│ BCP DEVELOPMENT LIFECYCLE │
│ │
│ Step 1: Business Impact Analysis (BIA) │
│ ↓ │
│ Step 2: Risk Assessment │
│ ↓ │
│ Step 3: Recovery Strategy Development │
│ ↓ │
│ Step 4: Plan Documentation │
│ ↓ │
│ Step 5: Testing and Exercises │
│ ↓ │
│ Step 6: Maintenance and Review │
│ ↓ │
│ [Loop: Regular review cycle; update │
│ when organisation or risks change] │
└─────────────────────────────────────────────────┘
Step 1: Business Impact Analysis (BIA)
The BIA is the foundation of your entire BCP. It identifies which processes are critical, what resources they depend on, and what happens when they're disrupted.
BIA Methodology
| Phase | Activity | Output |
|---|---|---|
| 1. Scope | Define which business units, processes, and locations to assess | BIA scope document |
| 2. Data collection | Interview process owners; collect data on processes, dependencies, impacts | BIA questionnaire responses |
| 3. Analysis | Determine criticality of each process; calculate impacts; set RTOs and RPOs | Process criticality ratings |
| 4. Validation | Review findings with process owners and senior management | Validated BIA report |
| 5. Prioritisation | Rank processes by criticality and recovery priority | Prioritised recovery list |
Key BIA Metrics
| Metric | Definition | Example |
|---|---|---|
| RTO (Recovery Time Objective) | Maximum time a process can be down before unacceptable impact | "Order processing must be restored within 4 hours" |
| RPO (Recovery Point Objective) | Maximum acceptable data loss measured in time | "We can lose up to 1 hour of transaction data" |
| MTPD (Maximum Tolerable Period of Disruption) | Absolute maximum downtime before the organisation's viability is threatened | "If order processing is down for >48 hours, we lose key customers" |
| MBCO (Minimum Business Continuity Objective) | Minimum level of service acceptable during a disruption | "Process 50% of normal order volume within RTO" |
Impact Categories
Assess the impact of disruption across multiple dimensions:
| Time Since Disruption | Financial Impact | Operational Impact | Regulatory Impact | Reputational Impact |
|---|---|---|---|---|
| 0–4 hours | Revenue loss begins; SLA penalties may start | Orders delayed; customer queries unanswered | — | Minor; mostly internal awareness |
| 4–24 hours | Significant revenue loss; penalty accumulation | Backlog builds; manual workarounds strained | NIS2/DORA notification may be triggered | Customers notice; social media mentions |
| 1–3 days | Major revenue loss; contractual breaches possible | Critical backlog; staff working overtime | Regulator enquiries likely | Media coverage possible; customer complaints |
| 3–7 days | Severe; potential customer loss; cash flow impact | Operations severely degraded; manual processes failing | Regulatory investigation possible | Significant reputational damage; customer churn |
| 7+ days | Potentially business-threatening | Business viability in question | Enforcement action likely | Long-term reputational damage; market share loss |
Step 2: Risk Assessment
Identify the threats that could disrupt your critical processes:
Threat Categories
| Category | Examples | Likelihood Considerations |
|---|---|---|
| Cyber | Ransomware, DDoS, data breach, supply chain attack | High and increasing; most common modern BCP trigger |
| Natural disaster | Flood, earthquake, severe weather, wildfire | Location-dependent; climate change increasing frequency |
| Technology failure | Hardware failure, software bug, cloud outage, network failure | Moderate; mitigated by redundancy and vendor SLAs |
| Supply chain | Key vendor failure, material shortage, logistics disruption | Moderate; concentration risk is the primary concern |
| Human | Key person loss, pandemic, strike, insider threat | Varies; pandemic risk demonstrated by COVID-19 |
| Facilities | Fire, building damage, power outage, access denial | Low-moderate; mitigated by remote work capability |
| Regulatory | Licence revocation, sanctions, forced shutdown | Low; but high impact |
Risk Scoring
For each threat, assess:
| Factor | Scale | Description |
|---|---|---|
| Likelihood | 1 (Very low) to 5 (Very high) | Probability of occurrence within 12 months |
| Impact | 1 (Minimal) to 5 (Catastrophic) | Impact on critical business processes |
| Risk score | Likelihood x Impact (1–25) | Prioritisation for mitigation and planning |
Step 3: Recovery Strategy Development
Based on your BIA (what needs to recover) and risk assessment (what might cause disruption), develop recovery strategies for each critical process.
Strategy Options by Resource Type
| Resource | Recovery Strategies |
|---|---|
| People | Cross-training; succession planning; work-from-home capability; temporary staffing agreements |
| IT systems | Redundancy (active-active or active-passive); cloud failover; backup and restore; manual workarounds |
| Data | Backup strategy aligned to RPO; offsite/cloud backup; data replication; immutable backups (for ransomware) |
| Facilities | Remote work; alternate site; hot/warm/cold site; coworking space agreement |
| Suppliers | Dual sourcing; pre-approved alternative suppliers; stockpiling critical materials |
| Communications | Redundant internet connections; backup phone systems; out-of-band communication channels |
IT Recovery Strategy Tiers
| Tier | Strategy | RTO | RPO | Cost | Use For |
|---|---|---|---|---|---|
| Tier 1 | Active-active (real-time replication) | Minutes | Near-zero | Very high | Mission-critical systems (payment processing, trading) |
| Tier 2 | Active-passive with automated failover | 1–4 hours | Minutes to 1 hour | High | Critical business applications (ERP, CRM, email) |
| Tier 3 | Warm standby with manual failover | 4–24 hours | 1–4 hours | Moderate | Important systems (HR, marketing, reporting) |
| Tier 4 | Backup and restore | 24–72 hours | 4–24 hours | Low | Non-critical systems (development, archives) |
| Tier 5 | Rebuild | 1–2 weeks | May lose recent data | Minimal | Low-priority systems |
Step 4: Plan Documentation
BCP Document Structure
| Section | Content |
|---|---|
| 1. Plan Overview | Purpose, scope, objectives, assumptions, dependencies |
| 2. Governance | BCP programme ownership, roles, responsibilities, review schedule |
| 3. Business Impact Analysis Summary | Critical processes, RTOs, RPOs, MTPDs, dependencies |
| 4. Risk Assessment Summary | Key threats, risk scores, mitigation measures |
| 5. Recovery Strategies | Per-process recovery procedures, alternate arrangements, resource requirements |
| 6. Activation Procedures | Criteria for plan activation; who can activate; notification cascade |
| 7. Response Procedures | Immediate actions for the first 24–72 hours by scenario type |
| 8. Recovery Procedures | Step-by-step procedures to restore each critical process |
| 9. Crisis Communication Plan | Internal, external, customer, media, regulator communication procedures |
| 10. IT Disaster Recovery Plan | Technical recovery procedures for each Tier 1–3 system |
| 11. Contact Directory | All key personnel, alternates, external parties, vendors, regulators |
| 12. Testing Programme | Testing schedule, types of tests, pass/fail criteria |
| 13. Maintenance Schedule | Review frequency, update triggers, version control |
| Appendix A | Detailed process recovery sheets |
| Appendix B | Vendor and service provider emergency contacts |
| Appendix C | System recovery documentation |
Step 5: Testing and Exercises
An untested plan is a wish list. Testing validates that your plan actually works.
Types of BCP Tests
| Test Type | Description | Complexity | Frequency |
|---|---|---|---|
| Plan review | Walk-through of the document to check accuracy and completeness | Low | Quarterly |
| Tabletop exercise | Facilitated discussion-based exercise with scenario injects | Medium | Twice per year |
| Component test | Test individual components (backup restore, failover, alternate site) | Medium | Quarterly |
| Simulation exercise | Full scenario simulation with real actions (but not actual disruption) | High | Annually |
| Full interruption test | Actual failover of systems and processes; production switches to DR | Very high | Annually for Tier 1 systems (if risk-appropriate) |
Tabletop Exercise Template
| Phase | Duration | Content |
|---|---|---|
| Setup | 10 min | Objectives, ground rules, scenario introduction |
| Inject 1: Disruption occurs | 20 min | Scenario unfolds; team discusses immediate actions, activation criteria |
| Inject 2: Escalation | 20 min | Situation worsens; communication decisions; resource allocation |
| Inject 3: Recovery | 20 min | Recovery begins; prioritisation decisions; customer communication |
| Inject 4: Complications | 15 min | Unexpected twist (e.g., backup failure, key person unavailable) |
| Debrief | 30 min | What worked, what didn't, action items |
Test Success Criteria
| Criterion | Pass | Fail |
|---|---|---|
| All critical processes recovered within RTO | Recovered within defined RTO | Exceeded RTO |
| Data loss within RPO | Data loss ≤ RPO | Data loss > RPO |
| All team members knew their roles | Team functioned per the plan | Confusion about responsibilities |
| Communication procedures worked | All stakeholders notified per plan | Missed or delayed notifications |
| Contact information accurate | All contacts reachable | Outdated phone numbers, emails |
| Alternate arrangements functional | Alternate site/systems operational | Alternate site not available or inadequate |
Step 6: Maintenance and Review
| Activity | Frequency | Trigger for Ad-Hoc Update |
|---|---|---|
| Full plan review | Annually | Major organisational change, acquisition, new regulation |
| BIA review | Annually | New critical process, significant process change |
| Contact directory update | Quarterly | Staff changes, vendor changes |
| Recovery strategy review | Annually | Technology change, new infrastructure |
| Post-test plan updates | After each exercise | Exercise findings and action items |
| Post-incident plan updates | After each activation | Lessons learned from real disruptions |
Business Continuity Plan Template
Process Recovery Sheet Template
Create one for each critical process:
| Field | Content |
|---|---|
| Process name | [e.g., Order Processing] |
| Process owner | [Name, contact] |
| Criticality | [Critical / Important / Standard] |
| RTO | [e.g., 4 hours] |
| RPO | [e.g., 1 hour] |
| MTPD | [e.g., 48 hours] |
| MBCO | [e.g., 50% normal volume within RTO] |
| Dependencies — IT systems | [List all systems required] |
| Dependencies — People | [Key roles and minimum staffing] |
| Dependencies — Vendors | [Critical vendor dependencies] |
| Dependencies — Facilities | [Physical location requirements] |
| Recovery strategy | [Description of how to maintain/restore this process] |
| Alternate arrangements | [What to do if primary recovery fails] |
| Step-by-step recovery procedures | [Numbered steps to restore this process] |
| Validation criteria | [How to confirm the process is functioning] |
BIA Template
BIA Questionnaire for Process Owners
| # | Question | Response |
|---|---|---|
| 1 | Describe the business process | [Free text] |
| 2 | What is the output/deliverable of this process? | [Free text] |
| 3 | Who are the customers (internal/external) of this process? | [List] |
| 4 | How many staff are involved in this process? | [Number] |
| 5 | What IT systems does this process depend on? | [System list] |
| 6 | What external vendors/suppliers does this process depend on? | [Vendor list] |
| 7 | What would be the financial impact per hour/day of this process being unavailable? | [Amount or estimate] |
| 8 | What would be the operational impact? | [Description by time period: 4h, 24h, 3d, 7d] |
| 9 | Are there regulatory obligations tied to this process? | [Yes/No + description] |
| 10 | What is the maximum acceptable downtime? | [Hours/Days = MTPD] |
| 11 | What is the minimum acceptable service level during disruption? | [Description = MBCO] |
| 12 | Can this process be performed manually? | [Yes/No + description] |
| 13 | Are there peak periods when disruption would be more severe? | [Description] |
| 14 | Are any staff uniquely skilled/knowledgeable for this process? | [Names = key person risk] |
Crisis Communication Plan
Communication during a crisis is often the weakest link. Prepare it in advance.
Communication Matrix
| Audience | Communicated By | Channel | Timing | Approval Required From |
|---|---|---|---|---|
| Executive team | Incident Commander | Phone/video call + email | Within 1 hour of activation | None (IC has authority) |
| All employees | HR / Communications Lead | Email + intranet + messaging platform | Within 4 hours | IC approval |
| Board of directors | CEO | Email + phone briefing | Within 4 hours for SEV-1 | CEO owns |
| Customers | Customer Success / Communications | Email + status page | Within 24 hours (or per contract SLA) | IC + Legal approval |
| Regulators | Legal / DPO | Formal notification channels | Per regulatory deadline (4h–72h) | Legal + DPO own |
| Media | Communications Lead / PR firm | Press statement / media briefing | Only if media enquires or public impact | IC + Legal + CEO approval |
| Vendors/partners | Procurement / Operations | Email + phone | Within 24 hours (critical vendors sooner) | IC approval |
| Insurance provider | Legal / Finance | Phone + formal notification | Within 24 hours | Legal approval |
Common BCP Mistakes
| # | Mistake | Consequence | Prevention |
|---|---|---|---|
| 1 | No BIA conducted | Recovery priorities based on assumptions, not analysis | Always start with a BIA; it's the foundation |
| 2 | Plan too long and complex | Nobody reads it; unusable during a crisis | Keep it action-oriented; use checklists and recovery sheets |
| 3 | Never tested | Plan has gaps; staff don't know their roles; recovery fails | Test at least annually; tabletops twice per year |
| 4 | IT-only focus | Ignores people, processes, vendors, facilities | BCP covers the entire business, not just IT |
| 5 | Outdated contact information | Can't reach key people during a crisis | Update contacts quarterly; verify after any staff change |
| 6 | No crisis communication plan | Inconsistent or delayed communication damages trust and violates regulations | Pre-draft templates; define who communicates to whom |
| 7 | Single point of failure in the plan itself | Plan stored only on a server that's down during the incident | Store plan in multiple locations (cloud, printed, offsite) |
| 8 | No consideration of supply chain | Critical vendor failure takes you down with them | Include vendor dependencies in BIA; develop alternative sourcing |
| 9 | RTO/RPO not aligned with IT capability | Business expects 4-hour RTO but IT can only deliver 24 hours | Align BIA requirements with IT investment and capability |
| 10 | Plan treated as a one-off project | Becomes outdated within months | Assign ongoing ownership; schedule regular reviews |
Frequently Asked Questions
How often should a business continuity plan be tested?
At minimum: full tabletop exercise twice per year and a technical recovery test (failover) annually. DORA requires financial entities to test ICT business continuity plans at least annually. After any major organisational change (restructuring, new systems, acquisition), conduct an additional test. Component tests (backup restore, communication cascade) should happen quarterly.
What's the difference between BCP and disaster recovery?
A BCP covers the entire business — people, processes, technology, facilities, and supply chain. A disaster recovery plan (DRP) is the IT-specific subset that covers the technical recovery of systems and data. Every BCP should include a DRP, but a DRP alone is not a BCP. Think of it this way: the DRP gets your servers back online; the BCP gets your business back operating.
How long does it take to develop a BCP?
For a mid-sized organisation, expect 3–6 months for a comprehensive BCP programme: 4–6 weeks for the BIA, 2–3 weeks for risk assessment, 3–4 weeks for recovery strategy development, 3–4 weeks for documentation, and 2–3 weeks for the first round of testing. Smaller organisations can compress this to 6–10 weeks with dedicated effort.
Is ISO 22301 certification worth pursuing?
ISO 22301 certification is valuable if your customers, regulators, or industry expect formal business continuity management. Financial services, healthcare, and critical infrastructure organisations benefit most. The certification provides a structured framework (similar to how ISO 27001 structures information security) and third-party assurance. If you're already pursuing ISO 27001, adding ISO 22301 leverages the shared management system structure.
How do BCP requirements differ between NIS2 and DORA?
NIS2 requires "business continuity and crisis management" as part of cybersecurity risk management measures (Article 21(2)(c)), including backup management and disaster recovery. DORA is more prescriptive: it requires a specific ICT business continuity policy (Article 11), ICT response and recovery plans (Article 12), backup policies and procedures, and testing at least annually (Article 13). Financial entities subject to DORA should align their BCP with both DORA and NIS2 requirements.
What should the RTO be for critical systems?
There's no universal answer — RTO depends on the business impact of downtime. Use your BIA to determine the financial, operational, regulatory, and reputational impact at various time intervals. Common benchmarks: mission-critical systems (payment processing, trading): minutes to 1 hour; business-critical systems (ERP, email, CRM): 4–8 hours; important systems (HR, reporting): 24–48 hours. The RTO must be achievable by your IT recovery capability — if not, invest in better recovery infrastructure or adjust business expectations.
How do we handle business continuity for remote/hybrid workforces?
Remote work has simplified some aspects of BCP (no single office dependency) but complicated others (more distributed IT, home network security, employee wellbeing during extended disruptions). Key considerations: ensure all employees can access critical systems remotely; have backup communication channels if primary tools (Slack, Teams) fail; maintain physical security for home workers handling sensitive data; consider the impact of regional internet outages on distributed teams.
What is the relationship between business continuity and cyber insurance?
Cyber insurance policies increasingly require evidence of business continuity planning as part of the underwriting process. A documented, tested BCP can help secure coverage and may reduce premiums. During an incident, the BCP guides recovery while the insurance policy covers costs. Notify your insurer early in any incident that may trigger coverage — many policies require notification within 24–72 hours. For a complete breakdown of coverage types, exclusions, and how to choose a policy, see our Cyber Insurance Guide.
Related Resources
- Incident Response Plan Guide — Complementary to BCP — covers the security incident handling that may trigger business continuity activation
- DORA Compliance Guide — DORA's ICT business continuity requirements for financial entities
- NIS2 Directive Complete Guide — NIS2 business continuity and crisis management obligations
- ISO 27001 Implementation Guide — ISO 27001's business continuity controls (A.5.29–A.5.30)
- Virtual CISO Guide — How a virtual CISO oversees BCP development and testing
Related Articles
- Incident Response Plan Template & Guide — Building a cyber incident response plan with templates
- DORA Compliance: The Complete Guide — Digital operational resilience for financial entities
- Information Security Policy Templates Guide — Building your security policy library for compliance
Conclusion
A business continuity plan is an investment in resilience. The organisations that survive and recover from disruptions aren't necessarily the ones that prevent every threat — they're the ones that plan for disruption, practise their response, and adapt continuously. Start with a business impact analysis, build recovery strategies that match your risk appetite, document clear procedures, test relentlessly, and keep the plan current.
Need help with business continuity planning? Vision Compliance builds business continuity programmes from BIA through testing — aligned with ISO 22301, NIS2, and DORA requirements. Schedule a free consultation →
Sources: ISO 22301:2019, BCI Good Practice Guidelines, DORA (EU 2022/2554), NIS2 Directive (EU 2022/2555), ISO 27001:2022, NIST SP 800-34 Rev. 1
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.