Business continuity plan
1. VERSION HISTORY
| Version No. | Revision Date | Author | Reviewed And Approved By | Changed For |
|---|---|---|---|---|
| V. 1.0 | 28-05-2020 | Parveen Kumar | DevOps Function | No |
2. AMENDMENT HISTORY
| Version | Date | Author (Function) | Reviewed By | Approved By | Nature Of Changes |
|---|---|---|---|---|---|
| Issue 1.0 | 23-05-2020 | Parveen Kumar | DevOps Function | Gaurav Sharma | First Integrated Issue |
3. APPENDIX: ANNUAL REVIEW HISTORY
| Annual Review Conducted On | Version Reviewed | Is Change Required (Y/N) | Remarks |
|---|---|---|---|
| Version 1.0 | 29-05-2020 | N | Ok |
4. INTRODUCTION
The Purpose Of Developing A Business Continuity Plan For Robotic Wares Pvt. Ltd. (Hereinafter RWPL) Is To Ensure The Continuation Of The Business During And Following Any Critical Incident That Results In Disruption To The Normal Operational Capacity.
In The Event Of A Disaster Which Me Disrupt The Services Of Fareye SaaS Services, This Document Is To Be Used By The Responsible Individuals To Coordinate The Fareye’s System Recovery. The Plan Is Designed To Contain, Or Provide Reference To, All The Information That Might Be Needed At The Time Of The Recovery. This Plan Is Design To Ensure Business Continuity Of Fareye SaaS Service Offering.
*This Plan Is Not Intended To Cover Business Continuity For Operations Team Of Fareye.
5. BUSINESS CONTINUITY MANAGEMENT AT FAREYE
FarEye Is Committed To Its Critical Business Processes And That Of Its Valued Customers. The Resilience Of Fareye To Ensure High Availability Of Its Services To Customers During Contemplated Business Disruptions And Thereafter Until Resumption Of Business As Usual. In Order To Comprehend The Viability And Readiness Of Its Business Continuity Management, The Exercising Of BCP/DR Drills Through Auditable Plan, Execution, Inference And Incorporation Of Lessons Learnt Are Institutionalized. To Augment The Customized BCP For Its Adequacy And Effectiveness, The Framework Is Aligned To Meet The ISO22301:2012 Standards (Earlier BS25999).
The Objective Of This BCP, Developed In Line With Fareye’s Corporate-Level BCMS Policy, Is To Prevent & Contain Potential Disruption Of Services To Its Operations Having An Impact On Its Customers And To Associates. It Lays Down The Communication, Escalation And Actions Necessary In The Event Of An Incident Or Business Disruptive Situation. It Will Provide Fareye With A Well-Researched Approach And Process To Resume Services At Acceptable Service Levels Within Acceptable Periods With A View Of Minimizing The Business Losses And Provide Cost-Effective Measures While Providing Alternate Services.
6. BUSINESS CONTINUITY PLANNING AT FAREYE
7. BUSINESS CONTINUITY STRATEGY
This Section Of The Fareye Business Continuity Plan Describe The Strategy Devised To Maintain Business Continuity In The Event Of Any Kind Of Technical Disruption In To The Fareye SaaS Services. Fareye Offerings Are Technology Driven Therefor Always Ensured To Automatically Recover From A Disaster.
a. PREVENTIVE MEASURES
This Sub-Section Cover All The Measures Are Taken To Ensure The High-Availability Of Fareye SaaS Services.
Data Center/ Cloud Infrastructure
Fareye Application Is Hosted On AWS Cloud Which Operates In Multi-Availability Zones.
Application Load Balancer
The Application Load Balancer Works As Single Point Of Contact For The Clients. It Distributes Incoming Application Traffic Across Multiple Application Nodes. The Application Load Balancer Is Configured In High-Availability Mode To Ensure Uninterrupted Services.
Application
The Application Nodes Are Configured In Clustering Mode To Ensure High-Availability And To Minimize The Dependency On One Application Node. Enough Buffer Resource Has Been Maintained In All Application Modes, So It Doesn’t Get Stuck At Peek Time.
Database
The Database Also Configures In Clustering Mode To Ensure High - Availability. Enough Resources Have Been Kept In Buffer, So It Keeps Functioning Even In Peak Time With High Load.
Recovery Priority
The Strategy Is To Recover Critical Services Of Fareye On High Priority. This Can Be Possible If A Recovery Strategy Has Been Put Into Effect By DevOps/Technology Teams To Provide The Recovery Services. A List Of Key Services And Key Customers Should Be Available With Respective Technology Operation Team.
The Services Which Are More Critical For Fareye And May Impact Majority Of Client And Fareye Services, Should Be Prioritized For Recovery.
8. SCOPE - CRITICAL PROCESS
This Document Covers All The Following Areas.
- Fareye Application System
- Database System
- Network Infrastructure
- Server Infrastructure
- Data Storage And Backup System
- Mobile Application
- Integration Platform
- Cloud Infrastructure
NOTE: This Document Does Not Cover Fareye Operations Team And Internal Function. Please Refer Process Specific BCP Plan For The Same.
9. BCP/ DR DRILL
To Test The Effectiveness Of Business Continuity Plan & Scenarios Defined In The Plan, Fareye Has BCP/DR Drill Plan In Place.
Drill Cycle
There Is A Monthly Drill Cycle Is Defined To Be Carried Out. These Drills Are Conducted Against The Scenarios Defined In This Document And To Check The Readiness Of BCP/DR Plan.
Soft BCP/DR Drill
Soft Drills Are Conducted On Monthly Basis For Fareye Application Where The Last Backup Of Database & File Systems Are Being Restored And Tested.
Hot/BCP DR Drill
Hot Drills Are Conducted On Yearly Basis For Fareye Application Where We Run The Production Environment From The Backup Availability Zone Post Temporarily Shutting Down The Primary Availability Zone.
BCP/ DR Reports
Drill Report Can Be Shared With The Customer Upon Customer Request.
10. RECOVERY PROCEDURE OF CRITICAL PROCESSES
The Scope Includes Complete Failure Scenarios And Other Failure Scenarios In The Different Business Functions For Fareye Application
a. RECOVERY PROCEDURE OF CRITICAL PROCESSES
Though This Is Most Unlikely Scenario For Fareye As We Are Running Our Database In Cluster Mode From Multi Availability Zones. Still, Fareye Has Requisite Business Continuity Planning And Disaster Recovery Process In Place To Ensure Uninterrupted Services To Clients And Shall Also Provide All Reasonable Assistance To The Clients In Its Business Continuity Planning Procedures.
In Case Of Complete Database Crash. Maximum Of 4 (Four) Hours (RTO) With Recovery Point Of 24 Hours (RPO) — Recovered From Last Transactional Log Backup, From One Or More Locations Due To Any Unforeseen Event. The TATs And Service Levels Will Be Suspended During This Time.
Declaration Of This Scenario Will Be Done By The Emergency Management Team
i. Complete Application Crash
Though This Is Most Unlikely Scenario For Fareye As We Are Running Our Services From Multi Availability Zones. Still, Fareye Has Requisite Business Continuity Planning And Disaster Recovery Process In Place To Ensure Uninterrupted Services To Clients And Shall Also Provide All Reasonable Assistance To The Clients In Its Business Continuity Planning Procedures.
In Case Of Complete Application Crash. Maximum Of 4 Hours (RTO) With An RPO Of 24 Hours From One Or More Locations Due To Any Unforeseen Event, Fareye Will Start The Provision Of The Service From DR Sites Within Four Hours. The TATs And Service Levels Will Be Suspended During This Time. Declaration Of This Scenario Will Be Done By The Emergency Management Team
ii. Other Scenarios
This Section Lists Out The Other Failure Scenarios Of Application And Database Services.
First Response By Email : support@fareye.com - App Support Helpdesk Function Replies To The Emails Received From The Employees Of The Client. Query Is Logged Under Fresh Desk, Every User On A First Come First Serve Basis. The Same Query Appears In The New List Of Every Associate. Any Response Received From The SPOCs Will Be Redrafted And Forwarded To The Employee As Resolution. Query Is Closed In The Case Management Tool (Freshdesk Tool) If The Complete Resolution Has Been Provided To The Employee.
Scenario 1– Issue In Fareye Application (Any Specific Module Is Not Accessible)
Recovery Procedure:
Restoring A Day-Old Fareye Application Configuration From Backup Server. BCP Activation Time 15 Min
Recovery Time Objective (RTO) 4 Hours
Recovery Point Objective (RPO) 24 Hours
Recovery Location
Office: RWPL, 5th Floor
Lotus Business Park, Plot 6,
Noida, 201304
Datacenter: AWS
Recovery Steps — Summary
Client To Be Notified Immediately By Respective SPOCs.
Responsibility
Respective Technology Leads, IT, DevOps, Application Support
Scenario 2 – Issue In Application Database
This Scenario Takes Care Of The Business Outage Due To Database (May Be Partial Or Complete Damage)
Partial Damage
All The Scenarios Covered The Partial Damage (Due To Database Corruption, Deletion, Etc.) That Impact Database Comes Under This Category.
RTO For Partial Damage: 4 Hrs
RPO For Partial Damage: 24 Hrs.
Complete Damage:
All Scenarios Covered In “Complete Failure Scenarios” And Damage That Impact Database Come Under This Category.
RTO For Complete Damage: 4 Hrs.
RPO For Complete Damage: 24 Hrs.
Recovery Location
Office: RWPL, 5th Floor
Lotus Business Park, Plot 6,
Noida, 201304
Datacenter: AWS
Responsibility
Respective Team Leaders, IT, Cloud-Ops, DBA, Application Support
Notification
| Sr. | Layer | Activity | Responsible | Accountable | Consult | Inform |
|---|---|---|---|---|---|---|
| 1 | EM (Event Management) | Call Logging With Support Desk Or Freshdesk Tool (Support@Getf Areye.Com ) | Support Team | Support Team Manager | Standard Operating Procedures And Vendor Support Directory | DevOps - SME, CISO TEAM, Other Impacted Function |
| 2 | CCP | Notify Vendor And Internal SME’s | Support Team | Support Team Manager | Process SME | DevOps - SME, CISO TEAM, Other Impacted Function |
| 3 | CCP | Notify Vendor To Initiate Supplier Continuity Plan To Provide Support And Monitor | ||||
| 4 | CoB | Technology Impact Analysis For Support Function And Service Delivery Unit | Process Team, Information Security Team | Process Lead | DevOps Lead-Service Notification To All Stake Holders | |
| 5 | CoB | Activate Plan – Tech Infra, DevOps, Service Delivery Unit, And Supply Chain Providers | Process Head, CISO | DevOps Manager, Process Manager | DevOps-SME, CISO TEAM, Business Head | |
| 6 | EM | Event Communication | Support Team | Process Lead | DevOps-SME, CISO TEAM, Business Head | |
| 7 | CoB | Business Or Support Unit Business Impact Assessment And Continuity / DR Action Plan Activation | Service Delivery Unit, Information Security Team | Function Head | Support Team | Service Delivery Head, Stake Holders |
| 8 | EM | Continuity Event Management ROTA For First Assessment Of Impacted Business Units For Appropriate And Adequate Strategy Activation Requirements In Lieu Of The IT Operations Disruption Notified By Service Desk | Service Delivery Unit BCL, DevOps Lead, CISO TEAM | Service Delivery Head, DevOps Head, CISO TEAM | SLA With Vendors. RTO And SLA Per Business Needs RTO Aligned To Business Needs And Customer Alignment | Service Delivery Head, Function Head, Customer Communicat E On, Associates Engaged In The Event, Stake Holders |
| 9 | PS | Ensure SME’s Are Provided With Transport And Guest House Facilities For Extended Outage Periods | Process Manager/ | Admin Manager | Email Communication | Process Head, Function Head, Admin Manager |
| 10 | AP | IT Infrastructure, Damage Assessment And Insurance Claims | Location Finance / Admin Manager | Location Finance / Admin Manager | Process Lead ,Admin, Finance | Management |
| 11 | ES | HVAC At Premises Available For Operations Recovery | Location ADMIN Manager | Location ADMIN Head | Supply Chain Location PRAC | Council, Business Leaders, LC, MSACF |
| 12 | CoB | Monitor The SLA Agreed Vs SLA Delivered For RTO Alignment And Change Recommendation Ns In Post Event Action Plan. List Of Vendors, Services, SLA Agreed Vs SLA Delivered | DevOps, Service Delivery Unit Head, Information Security Team | CISO TEAM | BCL Team | CISO And Service Delivery Head |
| 13 | CoB | Assess BIA, Announce Plan Upto Week 2 And Monitor To Report Every Week Meeting | BCL, Function Heads And Support Teams | Function Heads | Function Head And CISO Team | Council, Admin, DevOps, CISO Team ,Leadership Council |
| 14 | CoB | Recovery And Restoration Of Operations | Service Delivery Unit, DevOps | Service Delivery Unit, DevOps | BC Plans, Customer Priority If Any, RTO And/Or SLA | Leadership Teams |
| 15 | CoB | Announce Return Of Business To Normal | Function Head | Management Security And Continuity Forum Chair | Services Delivery Unit Head | MSACF Location Council |
| 16 | ATR | After Event Meeting And Action To Owner Tracking | CISO Team | Function Head | Support And Business Teams | Management |
| 17 | ATR | Track Actions To Closure | CISO Team | Function Head | Support And Business Teams | Management |
| 18 | ATR | Report Risk Exposures To Management Security Forum | CISO Team | Function Head | Support And Service Delivery Unit | Management |
| 19 | ATR | Actions Track Management Security Forum Continuity Improvement Plan | CISO Team | Function Head | Support And Service Delivery Team | Management |
iii. INCIDENT REPORTING
The PM/BCL Shall Ensure That The ADMIN Manager / CMT Leader/ERT Of The Location And Or IS Team Are Informed Of Disruptions Of The Incident At The Earliest. Further, Periodic Communication Will Happen To Keep All Stake Holders Posted On The Progress.
The PM/BCL Shall Document And Share The Incident Report To Relevant Stakeholders, Including IS Team. The Incident Management Process Will Be Followed To Ensure Prompt Alerts And Incident Handling. Incident Escalations Will Follow The Communication Plan Mentioned In The BCP.
Incident Report For Emergency Template Is Available At BMS /Web Qualify.
11. INCIDENT RESPONSE COMMAND STRUCTURE AND CONTROL FLOW
The Response Ownership During Disruption Needs Effective Command Structure For Execution Of Planned Activities, Spot Decisions And Contingency Strategies. Within The Scope Of The Business Requirements Of The Project/ Business Unit, The Authority And Segregation Of Accountability Is Tabulated Below To Ensure Effective Governance And Planned Execution.
| Sr. No. | Activity | Owner |
|---|---|---|
| 1 | Reporting Of The Incident | First Respondent |
| 2 | Record As An Incident | Support Team |
| 3 | Assessment Call To Classify The Incident In Scope Of Cyber Security | SME – DevOps, Service Delivery Unit, CISO Team |
| 4 | Severity Assessment – Cyber Security – IT Infrastructure, DevOps To Assessment Of Applications/Data Base Infrastructure | DevOps, Service Delivery |
| 5 | Severity Assessment Review – Infrastructure, Data, Apps | CISO Team |
| 6 | Assessment Call (CISO TEAM Is The Lead Assessor Of The Cyber Event Call) | CISO Team, DevOps Stake Holders |
| 7 | Assessment Call Agenda Discussion Environment Impact Cyber Infra, DevOps, Apps, Database, Business Impact Analysis Business Operations Impact – Immediate Impacts And RTO Brief As Per Documented BC Plans Decision To Activate Business Continuity Plans For Selective Or All | Admin, DevOps, CISO Team |
| 8 | Notification To Stake Holders | CISO Team / DevOps |
| 9 | Business Units/ Delivery Team/ Function Unit To Communicate To Partners, Customers, Teams Around Impact And Readiness With Continuity Plans And Actions Summary | Project Lead, Function Head |
| 10 | Monitoring Cyber Event Management To Closure – End To End | CISO Team |
| 11 | IMS Records And Governance | CISO Team |
12. COMMUNICATION TO CLIENT AND STAKEHOLDER
The Communication Team Will Be Responsible For Informing Clients About The Disaster And The Impact. The Best And/Or Most Practical Means Of Contacting All The Clients Will Be Used With Preference On The Following Methods (In Order):
- E-Mail (Via Corporate E-Mail Where That System Still Functions)
- E-Mail (Via Non-Corporate Or Personal E-Mail)
- Telephone To Employee Home Phone Number
- Telephone To Employee Mobile Phone Number
The Clients Will Need To Be Informed Of The Following:
- Anticipated Impact On Service Offerings
- Anticipated Impact On Delivery Schedules
- Anticipated Impact On Security Of Client Information
- Anticipated Timelines
Communicating To Partners
After All The Clients Have Been Informed About The Disaster, The Communication Team Will Be Responsible For Informing Partners Of The Disaster And The Impact.
Crucial Partner Will Be Made Aware Of The Disaster Situation First. Crucial Partners Will Be E-Mailed First Then Called To Ensure That The Message Has Been Delivered. Required Support Should Be Taken From The Partner At Time Of Disaster To Restore To The Normal Operation. All Other Partners Will Be Contacted Only After All Crucial Partner Have Been Contacted.
Communicating To Other Stakeholder
The Communication Team Will Be Responsible For Informing The Remaining Stakeholders Of The Disaster And The Impact.
13. POST DISASTER ACTIVITIES
Once The Disaster Has Been Controlled And Business Resumes Back To Normal State, Following Tasks Should Be Carried Out As Part Of Post Disaster Activities
- Return To Normalcy After Restoration Services.
- Lessons Learnt/Key Learning’s Would Be Update In BCP – If Required.
- The PM/BCL Shall Create Incident Report Stating Details Of Disaster And Impact Realized.
- Identify Impacted Business Functionality And Recovery Mechanism If Any.
- Identify Impact On SLA Adherence If Any.
- Carry Out Root Cause Analysis For The Disaster And Action Item For The Team If Any.
14. MANDATORY DOCUMENTS NEEDED
| Sr. No. | Document |
|---|---|
| 1 | RA & RTP Of The Project/ Business Unit |
| 2 | Project Specific Installation & Configuration Procedures |
| 3 | Project Management Data Repository / Details |
| 4 | BIA Assessment |
| 5 | Write-Up / SOP On Each Of The Critical Processes Declared |
| 6 | BCP/DR Drill Evidences |
| 7 | Incident Response Procedures For Identified Threats |
| 8 | Incident Report Document |
| 9 | Critical Resource Contact List |
15. MANDATORY DOCUMENTS NEEDED
| Sr. No. | Acronym | Expanded Form |
|---|---|---|
| 1 | BCM | Business Continuity Management |
| 2 | BIA | Business Impact Analysis |
| 3 | BCP | Business Continuity Plan |
| 4 | DR | Disaster Recovery |
| 5 | RTO | Recovery Time Objective |
| 6 | MAO | Maximum Acceptable Outage |
| 7 | MBCO | Minimum Business Continuity Objective |
| 8 | RA/RTP | RA/RTP |